简介这一离线安装包面向需要在无外网或内网环境部署 MySQL 5.7.40 的运维与开发人员适用于 Linux glibc2.12、x86_64 架构的系统省去手动编译或在线安装的麻烦。资源共 379 个文件压缩包大小约 646.59MB其中包含 104 个头文件、89 个动态库以及 25 个 XML 配置、9 个 SQL 脚本、多个初始化与启动脚本如 mysql_install_db、mysqld_safe和 mysql、mysqldump 等常用客户端工具解压后即为完整的服务器目录结构。已有748人学习下载。该资源不仅提供可直接运行的二进制程序还附带了默认配置文件、日志轮转脚本、man 手册和许可证说明方便离线环境下的快速安装与维护。结合描述中的初始化、权限设置、安全加固步骤可显著降低部署门槛尤其适合无法访问外部软件源的内网主机能一站式完成从解压到启动的全部流程也适用于版本升级或生产环境迁移场景。1. 认识这个安装包mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz 到底解决什么问题如果你正在翻这个标题大概率已经踩了一次互联网的边——生产内网、客户现场、专有云环境这些地方没有外网yum 源是空的apt 也用不了Docker 镜像拉不下来。这时候看到一个 mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz 离线安装包你会本能地想这是不是拷过去解压就能用的完美方案先说结论是但不是你想的那么“解压即用”。这个文件是 MySQL 官方发布的 Linux 通用二进制包glibc2.12 意味着它编译时链接的 glibc 最低版本是 2.12向下兼容 CentOS 6/7、Ubuntu 14.04 这些老系统x86-64 限定了 CPU 架构ARM 机器直接排除。它适合的目标场景很明确CentOS 7.x 最主流RHEL 7.x、Oracle Linux 7.x 也没问题Ubuntu 16.04 及以上也能跑。它帮你免掉了源码编译的 gcc、cmake、boost 依赖地狱也免掉了 rpm 包拆包时的一堆依赖纠葛但初始化实例、调参数、接 systemd、处理旧的 socket 和 pid 文件这些活儿一步都省不了。本文按我日常给客户做离线部署的套路把这个安装包从解压到开机自启完整捋一遍顺带把那些翻车概率极高的隐藏坑提前标出来。2. 部署前的三个环境检查别让离线包败给系统依赖2.1 检查 glibc 版本文件名不是摆设拿到 mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz 的第一件事不是急着解压而是确认这台机器的 glibc 版本是否满足要求。很多人的血泪教训是包拷过去了解压了mysqld 一启动就报/lib64/libc.so.6: version GLIBC_2.14 not found然后卡在那边怀疑人生。这个报错基本就是系统 glibc 太老跑不动这个二进制包。# 查看系统 glibc 版本 ldd --version | head -1 # 或者直接查 libc.so.6 的版本信息 strings /lib64/libc.so.6 | grep GLIBC_ | tail -5我一般习惯两条命令都跑一遍因为ldd --version在某些精简系统上输出的可能是ldd (GNU libc) 2.12而strings那条能列出所有可用的 GLIBC 符号版本。只要能看到GLIBC_2.14及以上mysql-5.7.40 就能正常拉起。如果系统是 CentOS 6.xglibc 默认是 2.12而 MySQL 5.7.40 官方包要求的最低版本实际是 2.14所以 CentOS 6 反而要小心可能得找老一点的 MySQL 5.7.x 小版本或者干脆用源码编译。这里先确认版本再继续下一步能省掉后续一小时的排障。还有一个容易漏的检查点是否有 32 位库混入的旧环境、是否装过奇怪的兼容层这些会导致 mysqld 启动时行为异常。最稳的办法是file mysqld确认它是 64 位 ELF然后看它链接到的库是否都能找到。# 解压前先看二进制类型 file /tmp/mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz/mysql-5.7.40-linux-glibc2.12-x86-64/bin/mysqld # 查看缺失的动态库 ldd /tmp/mysql-5.7.40-linux-glibc2.12-x86-64/bin/mysqld | grep not foundldd输出里有not found就是致命的最常见的是缺libaio.so.1这个库在 CentOS 7 默认不一定装Debian/Ubuntu 系也经常没有。解决办法就是离线环境下找到系统安装光盘rpm 方式装一下 libaio或者从另一台同系统的机器上直接 copy 这个 .so 文件到/lib64/。另一种做法是先看libnuma相关的库MySQL 5.7 在某些 NUMA 场景下也会因为缺 libnuma 启动失败不过 libaio 是出现频率最高的那个坑。2.2 检查数据目录规划离线安装最忌讳乱放二进制包自带一套默认目录结构但它可不会自动帮你创建数据目录、日志目录和 socket 目录。如果按照 tar 包解压后的默认布局直接跑数据文件会落在安装目录下的 data 子目录里日志也会混在安装目录里后面磁盘满了、日志轮转、升级替换都会很痛苦。我一般的做法是把软件目录和数据目录分开软件目录只读数据目录独立挂载。# 我的习惯/data 作为独立数据分区软件放 /usr/local # 先建目录 mkdir -p /usr/local/mysql mkdir -p /data/mysql/data mkdir -p /data/mysql/logs mkdir -p /data/mysql/tmp # 创建专用用户 useradd -r -s /sbin/nologin mysql这里的思路是把数据目录挂在大分区上避免 /usr 分区被数据库文件撑爆。useradd -r创建系统用户-s /sbin/nologin禁止该用户登录MySQL 初始化完成后 mysqld 进程会以 mysql 身份运行即使黑客拿到 MySQL 权限也进不了 shell。这个用户是必须提前建的因为初始化脚本mysqld --initialize需要以不存在的用户运行时会直接拒绝或者报错。2.3 磁盘空间与 inode 的检查解压时才发现空间不够是最尴尬的离线包本身只有几百兆但解压后加上数据库初始化的数据文件空间需求会涨。MySQL 5.7 初始化时默认会创建几个固定大小的系统表空间文件ibdata1 初始 12Mredo log 默认 2 个 48Mundo log 默认 2 个 16M这些加起来不大但你不可能知道后面业务数据要多大。所以我至少会确认目标目录有 2G 以上空闲并且 inode 足够。# 检查磁盘空间与 inode df -h /data df -i /data # 检查文件系统类型 mount | grep /datadf -i在 XFS、ext4 上一般没问题但某些云盘的默认文件系统如果是 vfat 或者老旧的 ext3inode 数量会非常紧张而 MySQL 的表结构文件是按张表几个文件来计算的一张 InnoDB 表至少表结构 .frm 和 .ibd 两个文件表一多inode 就烧得特别快。文件系统类型也很关键万一挂载的是网络文件系统NFSMySQL 的落盘性能和锁行为都会变得很怪直接建议换本地 SSD 盘。这一步不是可有可无的检查它决定了后面数据目录放在哪里不会出幺蛾子。3. 解压、软链、初始化数据目录从 tar.gz 到可启动实例的完整命令3.1 解压并布置目录结构很多第一次做离线安装的同学喜欢把文件解压到/tmp再挪到目标位置这个动作在数据量大时会白白多等好几分钟而且mv跨文件系统时是拷贝删除速度会慢到你怀疑机器卡死。正确做法是直接把 tar 包解压到安装目录用--strip-components1去掉外层目录。# 先把离线包放好比如放在 /tmp cd /usr/local tar -zxvf /tmp/mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz --strip-components1 # 查看解压结果 ls -lh /usr/local/mysql/bin/mysqld # 创建软链便于后续升级和维护 ln -s /usr/local/mysql /usr/local/mysql-5.7.40 # 设置目录归属 chown -R mysql:mysql /usr/local/mysql chown -R mysql:mysql /data/mysql--strip-components1的含义是解压时去掉第一层目录名这样解压出来的 bin、lib、share 等直接落在/usr/local/mysql下面而不是mysql-5.7.40-linux-glibc2.12-x86-64这个冗长目录里。软链的好处是以后升级时把新版本解压到新的软链目标业务路径不用变。很多人忽略的chown -R一定要做不然后面mysqld --initialize和启动都会因为目录权限不对而失败。这里插一个容易踩的细节解压后的 lib 目录里自带 libaio 的共享库但 mysqld 启动时不一定优先去 md 这个 lib 目录加载而是走系统的ld.so.conf路径。所以如果ldd检查时发现缺 libaio你还是得去系统层面解决不要天真地以为安装包自带的 lib 目录能兜底。有些发行版的 ld.so.conf 不会自动包含/usr/local/mysql/lib需要手动加到/etc/ld.so.conf.d/mysql.conf里然后ldconfig刷新缓存。# 注册 mysql 的 lib 目录到动态链接器 echo /usr/local/mysql/lib /etc/ld.so.conf.d/mysql.conf ldconfig # 再次确认依赖 ldd /usr/local/mysql/bin/mysqld | grep not found这一步做完依赖检查应该完全干净了没有任何not found输出。如果还有缺失按上一节说的去系统安装盘找 rpm 包装上装完再跑一次ldconfig直到输出为空再去初始化。3.2 my.cnf 配置初始化前必须先给好基础参数很多新手直接先mysqld --initialize再写 my.cnf这是顺序搞反了。初始化过程会读取配置文件来确定数据目录、socket 文件路径、错误日志路径如果初始化时没配置后面启动时改路径就会导致 mysqld 找不到初始化好的数据文件报错无法启动。所以正确的顺序是先写一个最小可用的 my.cnf再初始化再启动。# /etc/my.cnf [mysqld] user mysql basedir /usr/local/mysql datadir /data/mysql/data socket /data/mysql/tmp/mysql.sock pid-file /data/mysql/tmp/mysql.pid log-error /data/mysql/logs/error.log port 3306 server-id 1 # InnoDB 基础参数 innodb_buffer_pool_size 512M innodb_log_file_size 128M innodb_flush_log_at_trx_commit 1 # 字符集 character_set_server utf8mb4 collation-server utf8mb4_general_ci这个配置文件的路径/etc/my.cnf是 MySQL 默认的读取路径之一优先级最高。socket路径放在数据目录的 tmp 子目录里好处是和数据独立出来socket 文件是临时文件重启会重新生成这样即便删掉也不会影响数据。pid-file同理。error.log一定要配置不然启动失败时你都不知道去哪看错误信息。innodb_buffer_pool_size按物理内存的 50%~70% 配我这台测试机给 512M 只是先跑通流程。character_set_server写成 utf8mb4别再用老旧的 utf8 或者 utf8mb3不然存 emoji 表情会直接报错。3.3 执行 mysqld --initialize关键参数和日志观察MySQL 5.7 的初始化命令已经不再是scripts/mysql_install_db很多人还在用老命令会直接报找不到命令或者提示已废弃。新命令是mysqld --initialize它会自动创建系统表空间、系统库、system tablespace 以及一个带有临时密码的 root 用户。这个临时密码会写在错误日志里是后续登录的唯一凭证。# 切换到 mysql 用户执行初始化避免权限不一致 su -s /bin/bash mysql -c /usr/local/mysql/bin/mysqld --initialize --basedir/usr/local/mysql --datadir/data/mysql/data # 查看错误日志找到临时密码 grep temporary password /data/mysql/logs/error.log初始化成功的标志是错误日志里出现[Note] A temporary password is generated for rootlocalhost:这一行后面的字符串就是临时密码。如果日志里出现[ERROR]最常见的几个原因是datadir 不是空的之前初始化过或手动建过文件、datadir 目录权限不是 mysql 用户、libaio.so.1缺失。日志里[ERROR]后面跟的具体原因会很直白照着解决即可。--initialize还有一个--initialize-insecure变体区别是生成的 root 密码为空我们在生产上不推荐用这个测试环境图省事可以用但正式环境还是走临时密码这条链路更安全。另外注意一点--initialize只做初始化不会启动 mysqld。初始化完成你可以看到数据目录里出现了ibdata1、ibtmp1、undo_001、undo_002以及mysql、performance_schema、sys这几个目录。看到这些文件说明数据目录这块已经没问题了。4. 启动、接 systemd、改密码、开放远程登录让 MySQL 真正可用4.1 手动启动验证 配置 systemd 服务初始化完成先别直接上 systemd我习惯先手动启动一次看日志里有没有隐藏问题确认无误再固化成服务。手动启动有两条路mysqld_safe和直接mysqld。mysqld_safe是 5.7 时代的守护式启动方式它会监控 mysqld 进程状态并在崩溃时自动拉起但它的日志输出去向后台排障时反而不直观。我一般直接前台跑mysqld把错误日志定向到终端看输出。# 手动前台启动便于观察日志 su -s /bin/bash mysql -c /usr/local/mysql/bin/mysqld --basedir/usr/local/mysql --datadir/data/mysql/data如果启动成功终端会停住不返回不会有错误输出。此时另开一个终端登录验证。# 用临时密码登录 /usr/local/mysql/bin/mysql -uroot -p -S /data/mysql/tmp/mysql.sock # 登录成功后立即修改密码 ALTER USER rootlocalhost IDENTIFIED BY MyNewPass123!;这里用-S指定 socket 文件因为在 my.cnf 里我们把 socket 路径从默认的/tmp/mysql.sock移走了不带-S会提示找不到 socket 连接失败。改密码这一步 MySQL 5.7 默认开了 validate_password 插件密码必须含有大小写字母、数字和特殊字符且长度至少 8 位不然ALTER USER会报错提示密码策略不满足。临时密码登录后第一件事就是改密码不然日志里的临时密码如果被其他人瞥见就是个裸奔的账号。验证启动没问题后CtrlC 停掉手动进程配置 systemd 服务。systemd 是企业级 Linux 的标准进程管理方式用它管理的好处是开机自启、崩溃自动拉起、日志走 journald。5.7 的官方 tarball 里没有自带 service 文件需要手写。我把日常在用的模板贴出来里面有一些容易漏的细节。# /usr/lib/systemd/system/mysqld.service [Unit] DescriptionMySQL 5.7.40 Server Afternetwork.target Aftersyslog.target [Service] Usermysql Groupmysql Typeforking PIDFile/data/mysql/tmp/mysql.pid ExecStart/usr/local/mysql/bin/mysqld_safe --datadir/data/mysql/data --pid-file/data/mysql/tmp/mysql.pid ExecReload/bin/kill -HUP $MAINPID PrivateTmpfalse Restarton-failure RestartSec5s [Install] WantedBymulti-user.target这个文件的注意点在于Typeforking因为mysqld_safe是守护进程方式它会 fork 出子进程后自己常驻systemd 认为启动完成的标志是父进程 fork 成功。PIDFile必须和 my.cnf 里的路径一致否则 systemd 监控不到 mysqld 的实际 pid会导致重启时旧进程没被杀干净。ExecStart故意用的mysqld_safe而不是mysqld这样即使 mysqld 崩溃mysqld_safe 也能拉起它相当于自带一层兜底守护。PrivateTmpfalse是关键如果默认的 truemysqld 会看不到/tmp下的资源共享而 MySQL 内部的一些临时文件和套接字操作会用到 /tmp不关掉会出现诡异连接失败。配置完成后执行systemctl daemon-reload然后systemctl start mysqld再systemctl status mysqld确认状态是 active (running)。这一步如果失败去看 journald 日志和 error.log两个地方都要看因为 mysqld_safe 本身不写 error.log它的信息在 journald 里而 mysqld 的错误全在 error.log。systemctl daemon-reload systemctl start mysqld systemctl status mysqld # 查看启动日志 journalctl -u mysqld -f4.2 开放远程连接和使用 mysql_config 验证编译参数业务环境下你大概率需要用 Navicat、DBeaver 或者应用服务器连接数据库只留 localhost 是没法连的。MySQL 默认只允许 root 从本机登录而且我们不建议直接把 root 暴露给远程。标准做法是创建专门的业务账号授予最小权限并允许从指定网段访问。注意 5.7 的默认认证插件是caching_sha2_password还是mysql_native_password是有讲究的5.7 系列默认是mysql_native_password8.0 才是caching_sha2_password但有些老客户端只认 native password你在 5.7 上不用动这个也能兼容老客户端。-- 创建远程登录账号网段按实际环境调整 CREATE USER app_user10.10.0.% IDENTIFIED BY AppPass123!; GRANT ALL PRIVILEGES ON mydb.* TO app_user10.10.0.%; FLUSH PRIVILEGES;10.10.0.%是网段通配符它表示只允许 10.10.0.x 段的机器连接安全性好过%允许所有 IP。权限只给了mydb这一个库避免业务账号误删系统库。如果应用服务器跨网段访问可以调整这个 IP 模式但不建议开%。验证远程是否可连一般用另一台机器跑mysql -uapp_user -p -h 服务器IP -P 3306连不上的话优先查防火墙CentOS 7 的 firewalld 默认挡 3306 端口。这个不属于 MySQL 范畴但部署时十有八九会卡在这一步我直接给你一条命令自查firewall-cmd --list-ports # 如果没有 3306执行 firewall-cmd --zonepublic --add-port3306/tcp --permanent firewall-cmd --reload4.3 开机自启与常见配置参数确认systemd 服务配好后systemctl enable mysqld就完成了开机自启。但这里有个隐蔽坑如果你的环境里同时有多个 MySQL 实例或者自定义编译过的 MariaDBservice 文件名字不要撞车也不要覆盖别人已有的 mysqld.service。我遇到过一次某客户环境里自己写了个 mysqld.service 指向老版本我安装时覆盖了它结果一台机器上跑了两个实例把 3306 和 3307 全占了折腾了一个多小时才理清。开机自启后建议再做一次完整验证重启机器或者systemctl reboot等开机后检查systemctl status mysqld和mysql -uroot -p能否正常登录。这一步很多新手会偷懒跳过结果三个月后例行重启才发现数据库没起来业务中断。离线部署不比在线 yum 安装没有云端监控平台帮你盯自启验证就是保命的最后一环。5. 离线安装避坑手册我在生产环境踩过的 5 个最常见的坑5.1 初始化时报错ibdata1已存在原因是指定 datadir 下已有残留文件现象执行mysqld --initialize --datadir/data/mysql/data时日志报[ERROR] InnoDB: The file ./ibdata1 already exists初始化直接中断。新手会百思不得其解明明刚建的空目录为什么会有文件真实原因大概率是之前初始化过一次失败或者直接向 datadir 写过临时文件比如我自己调试时向 /data/mysql/data 里丢过一个测试文件之后就忘干净了。MySQL 的初始化对 datadir 有洁癖目录必须为空有任何非它创建的文件都会拒绝执行。解决清空 datadir 目录再重新初始化。但清空有风险如果之前有过一次成功的初始化只是中断了后续步骤千万不要盲目清。确认没有业务数据后执行rm -rf /data/mysql/data/* # 重新初始化 su -s /bin/bash mysql -c /usr/local/mysql/bin/mysqld --initialize --basedir/usr/local/mysql --datadir/data/mysql/data另外注意rm -rf的权限root 执行没问题但如果数据目录里已经有 mysql 用户创建的文件root 删不掉的话先chown -R root:root /data/mysql/data再删。血的教训提醒初始化前检查 datadir 是不是真空的可以省掉这一整段排障流程。5.2 启动时无法连接/data/mysql/tmp/mysql.sock原因是 socket 路径不一致现象mysql -uroot -p连接时报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock但是 mysqld 明明已经运行了。原因很简单mysqld 实际使用的 socket 路径是/data/mysql/tmp/mysql.sock但客户端默认去找/tmp/mysql.sock两边对不上。这个错误在最开始我写 my.cnf 时故意把 socket 指向自定义目录后必然会出现第一次用 mysql 客户端的人必然踩。解决连接时显式指定 socket或者在 my.cnf 的[client]段也配置同一个 socket 路径。前者是应急后者是根治。# 应急连接方式 mysql -uroot -p -S /data/mysql/tmp/mysql.sock更优雅的方案是在 my.cnf 里加[client]段让所有在本机使用 mysql 客户端的操作都自动带上正确的 socket 路径不需要每次输-S。这个配置值得长期放着因为后续执行定时备份脚本、主从复制脚本时凡是走 localhost 的 mysql 命令都会受益。[client] socket /data/mysql/tmp/mysql.sock5.3 系统盘 /tmp 空间不够导致内部临时表撑爆原因是 tmpdir 默认指向系统盘现象跑一个稍微大一点的排序或分组查询mysqld 报ERROR 1114 (HY000): The table /tmp/#sql... is full随后整个实例连接变慢。这是因为 MySQL 的排序、group by、以及某些 join 操作需要写内部临时表默认临时目录是/tmp而很多云主机/tmp和系统根分区共用空间很小通常是 2G 左右一跑大查询就写满。这个问题在离线部署时不容易被发现因为刚开始业务量小等到数据量上来才是引爆点但它在生产上相当常见。解决把 internal_tmp_disk_storage_engine 相关的临时目录迁移到数据目录所在大分区。在 my.cnf 里加一行tmpdir /data/mysql/tmp注意这个目录必须存在且 mysql 用户可写。前面建目录时我们已经建了/data/mysql/tmp而且 socket 文件也在那里一物两用。改完必须重启 mysqld 才会生效。遇到这种情况我还习惯顺带查一下max_heap_table_size和tmp_table_size如果内存足够大可以把这两个参数调大让更多临时表直接落在内存而不是磁盘。5.4 密码强度插件挡住业务需求原因是 validate_password_policy 太严格现象给业务账号设置一个简单密码时报ERROR 1819 (HY000): Your password does not satisfy the current policy requirements。5.7 初始化时默认启用了 validate_password 插件策略等级默认是 MEDIUM要求密码至少 8 位、含大小写字母、数字和特殊字符。这个策略对于生产环境是好事但在某些内部网络、非核心系统上业务方就是坚持要用 6 位短密码你需要在安全合规和业务便利间做个取舍。解决按需调整策略等级或干脆卸载插件。我一般保留插件但把策略降到 LOW只查长度不查复杂度-- 查看当前策略 SHOW VARIABLES LIKE validate_password%; -- 调整策略等级 SET GLOBAL validate_password_policy LOW; SET GLOBAL validate_password_length 6;如果要永久生效把这些参数写进 my.cnf 的[mysqld]段重启不丢。如果连长度也不想限制可以完全禁用插件在 my.cnf 里加validate_password OFF然后重启。我很少建议走到禁用这步因为 MySQL 5.7 里插件一旦完全禁用后面你想开回来还要重新 install plugin动作更多。5.5 端口被占用或者防火墙拦截3306 看起来没监听现象systemctl start mysqld返回成功但ss -lntp | grep 3306什么都没有外部连接全部超时本地 socket 连接却正常。这个坑最典型的场景是服务器上原本有个残留的 MariaDB 或之前装过的 MySQL 实例占用了 3306 端口你的 mysqld 启动时因为端口冲突自己改了端口绑定或者干脆启动失败journald 日志里有Bind on TCP/IP port: Address already in use。还有一种场景是 mysqld 成功监听了但 firewalld 在中间挡了一道外网根本进不来。解决先看端口再处理占用或防火墙。# 查看端口监听情况 ss -lntp | grep 3306 # 如果是其他进程占用确认业务可停后 kill 掉或者改自己的端口 lsof -i :3306 # 防火墙放行 firewall-cmd --zonepublic --add-port3306/tcp --permanent firewall-cmd --reload如果确认是自己的老实例占用且不需要保留systemctl stop那个服务再启动新实例即可。如果是新实例死活不监听多半是我前面说的bind-address没配置默认只绑定本机回环地址建议在 my.cnf 里显式写bind-address 0.0.0.0这样所有网卡都能接受连接。6. 存量数据迁移与性能验证把离线环境搬进生产前的一次完整检查6.1 用 mysqldump 迁移业务数据离线环境下的数据导入导出闭环离线安装不只是装一个新库大部分场景是把原来在线环境的库迁移进来。mysqldump 是 5.7 最通用的逻辑备份工具适合数据量在几个 GB 以内的迁移超过这个量建议走物理文件拷贝和 XtraBackup 方案。离线环境往往没有 XtraBackup 的离线包所以 mysqldump 是最稳妥的路径。# 导出在源库机器执行指定源 socket 和账号 /usr/local/mysql/bin/mysqldump -uroot -p --single-transaction --routines --triggers --events --databases mydb /data/backup/mydb.sql # 导入在目标机器执行 /usr/local/mysql/bin/mysql -uroot -p /data/backup/mydb.sql--single-transaction很关键它可以保证导出的数据一致性而不锁表InnoDB 引擎下这是必须加的选项。--routines、--triggers、--events是分别导出存储过程、触发器、定时事件这三样漏一个导入后业务就会缺功能。如果你备份的是多个库--databases会在 dump 文件里带上建库语句如果只备份单库里的若干表就不用--databases而是直接mydb table1 table2。导入后一定要验证表数量和关键表行数不要光看有没有报错就完事因为 MySQL 的 dump 脚本遇到权限不足时可能只是警告你很难察觉。导入到一半中断也是常事常见原因是 message 太大或者导入时 max_allowed_packet 不够导致的ERROR 2006 (HY000): MySQL server has gone away。解决办法是在目标库临时调大这个参数再导入导入完可以恢复原值。趁这个场景我把参数也一并写出来后面不需要再单独查文档SET GLOBAL max_allowed_packet 1024*1024*64;6.2 通过 mysqld 自带工具核对数据库文件完整性离线安装环境下没有外部监控平台最可靠的自检工具是 MySQL 自带的mysqlcheck和innochecksum。迁移完成后跑一遍这两项能给后续上生产吃一颗定心丸。mysqlcheck 负责逻辑层的表完整性检查innochecksum 负责物理页级的校验两边都过了再拿给业务方验收。# 检查所有库的表结构状态 /usr/local/mysql/bin/mysqlcheck -uroot -p --all-databases --check # 针对指定表做物理页校验需要先停止 mysqld 或锁表实际生产建议低峰期执行 /usr/local/mysql/bin/innochecksum /data/mysql/data/mydb/table_name.ibdmysqlcheck --check对一张损坏表会返回明确的错误信息比如Table ... is marked as crashed and should be repaired。看到这种输出先不要慌多数情况下只是索引损坏用mysqlcheck --repair修复即可。innochecksum是更底层的物理校验工具它逐页计算校验和发现任何一个页的校验和不对都会直接报错。这个工具通常在重点表上跑全库跑一遍时间成本高根据我经验挑核心业务表抽检就够了。6.3 参数调优技巧刚装完别急着动默认参数但有两个必须改新装的 MySQL 5.7 默认配置很多是针对小内存和通用场景的真实生产必须调但不是一股脑什么参数都改。我自己在 5.7 生产环境里调得最多的两个参数一个在前面已经提过innodb_buffer_pool_size另一个是innodb_flush_log_at_trx_commit。默认值是 1意味着每次事务提交都要把 redo log 刷到磁盘这在追求数据安全时是必须的但在写并发高的内部系统上每次 fsync 成了瓶颈。如果业务能容忍最多丢失 1 秒的事务这个参数可以调到 2性能收益在机械盘上尤其明显。# 按业务容忍度调整不是无脑改 innodb_flush_log_at_trx_commit 2 # 如果内存足够把 buffer pool 调大 innodb_buffer_pool_size 4G改参数后重启验证效果最简单的方式是看SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads的比值命中率在 99% 以上说明 buffer pool 大小合理如果大量读请求直接落在磁盘上说明 buffer pool 明显偏小加内存或者调大参数。这些调优没有标准答案参数值取决于机器配置和业务模型我习惯先用默认参数上线观察一周压测数据后再针对瓶颈调整而不是第一天就抄一整套高性能配置那样往往适得其反。6.4 临近收尾的检查清单把这些命令跑一遍才算真正交接我自己每在一台机器上完成离线部署最后都会按这个清单快速过一遍全部通过才敢跟业务方说“可以上线了”。这套检查相当于交付前的最后一关跑完心里踏实也方便后面排查问题时有基线比对。# 1. 确认服务自启 systemctl is-enabled mysqld # 2. 确认进程存活、端口监听 ps -ef | grep mysqld | grep -v grep ss -lntp | grep 3306 # 3. 确认关键变量生效 mysql -uroot -p -e SHOW VARIABLES LIKE character_set_server; SHOW VARIABLES LIKE datadir; SHOW VARIABLES LIKE socket; # 4. 确认账号权限 mysql -uroot -p -e SELECT user,host,plugin FROM mysql.user; # 5. 写入测试数据并立即查询 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS test; USE test; CREATE TABLE t1(id INT PRIMARY KEY); INSERT INTO t1 VALUES(1); SELECT * FROM t1;第五步很多人嫌多余但它在验证客户端和服务器之间权限、表空间创建和InnoDB写入链路都有用尤其是排查过 InnoDB 初始化问题的环境里这一步能让隐患现形。跑完这一套整个离线部署才能算闭环。再补一个我平时会做的小习惯把安装包备份到/data/backup目录里并把解压出来的版本号记录到一个文本文件里。这样做的好处是半年后如果要做版本兼容性排查你能立刻知道当前跑的是哪个编译版本的二进制包而不必去翻历史命令记录。环境部署这种事越是细节越见功底很多半夜接到故障电话的疲惫时刻最后救你的往往就是当初顺手记下的那几行备注。希望这篇笔记能帮你少走几趟弯路。本文还有配套的精品资源点击获取