前两天有个朋友半夜给我打电话，说他手贱把公司测试库的表给 DROP 了，问我有没有救。我说：“你有备份吗？”他沉默了三秒，然后问：“啥是 mysqldump ？”这事其实不怪他，刚入行的程序员谁没干过几件蠢事。但问题是，你备份了吗？你知道 mysqldump 是什么吗？它看起来就是个命令行工具，用好了是救命稻草，用不好就是定时炸弹。我见过太多人以为跑个 mysqldump 就完事了，结果还原时发现备份文件是空的，或者字符集乱成一锅粥，甚至备份了三天三夜还没完。今天咱就聊聊这个看似简单、坑却很多的工具，从实战角度说说怎么用才靠谱。
先说最基本的用法，很多人觉得 mysqldump 就是一行命令的事儿，实际上坑全在细节里。比如最简单的备份一个库，常见写法是 mysqldump -u root -p database > backup.sql。它能跑，但问题大了去了。你试试还原时，如果目标数据库的字符集不是 UTF8，中文全会变成问号。我建议养成加 --default-character-set=utf8mb4 的习惯，现在基本都用这个。还有 --single-transaction 这个参数，对 InnoDB 表来说非常重要，不加的话备份期间表会被锁住，线上业务直接就停了。要是用 MyISAM 表，那更得小心， mysqldump 默认会锁表，备份时业务写不进去，用户那边就会报错。所以备份前先弄清楚表的引擎，再决定加不加 --single-transaction 或 --lock-tables=false。
再说个常见的坑：备份大库时，直接 mysqldump 会把磁盘撑爆。我见过一个哥们儿，备份一个 200 GB 的库，结果备份文件直接膨胀到 150 GB，服务器磁盘报警了。为啥？因为 mysqldump 默认导出所有数据，包括索引、临时表等。你可以加 --compact 参数，去掉注释和多余格式，文件会小很多。更实用的是加 --where 条件，比如只备份最近一个月的数据，省事又省空间。还有 --no-data 只导出表结构， --no-create-info 只导出数据，这些组合起来用，能精准控制备份内容。压缩备份是必须的， mysqldump | gzip > backup.sql.gz ，文件能缩小到原来的十分之一。我习惯用 pigz 多线程压缩，速度更快，尤其是百 GB 级别的库，能省一半时间。
还原时，很多人直接 mysql < backup.sql ，这本身没问题，但要考虑几个细节。第一，目标数据库的字符集要和原库一致，不一致会导致数据乱。第二，表结构是否已经存在。如果目标库已有表，直接还原会报错，因为表已存在。这时可以加 --force 参数强制覆盖，但风险很大，误操作后果严重。我的建议是先建一个干净的库，然后用 mysql -u root -p newdatabase < backup.sql ，这样更保险。还有个技巧是分步还原：先导出结构，再导入数据，这样如果数据出现异常，至少结构是完整的，排查更方便。可以先用 mysqldump --no-data 导出结构，得到 struct.sql，随后 mysql newdatabase < struct.sql ，再 mysql newdatabase < data.sql ，虽然多了一步，但更稳当。
你们肯定遇到过这种情况：备份文件特别大，还原时跑了好几个小时，中途网络断了或终端关闭，前功尽弃。怎么办？可以用管道配合 screen 或 tmux 跑，保证任务不会因为断网而中断。更高级的做法是还原时加 --max-allowed-packet 参数，默认是 16M，超大的 SQL 语句会被截断导致还原失败。可以设大一点，比如 128M、256M，甚至 1G。还有 --netbufferlength ，默认 1M，调大一点可以减少网络包交互次数，提升速度。我见过有人还原 100 GB 的库，默认参数跑了一整天，调大后半天就搞定，差别真的很大。
说到备份策略，很多公司只在 crontab 里每天凌晨跑一次 mysqldump 并存本地。这风险太大，硬盘坏了怎么办？文件系统出问题怎么办？我建议至少保留三份备份：本地、一份远程、一份云存储。本地备份用 mysqldump 全量，增量备份则依赖 binlog。远程可以用 rsync 同步到另一台服务器，云端可以上传到 OSS 或 S3。备份文件还要定期做还原测试，别等到真出事才发现备份文件是坏的。曾有客户备份文件存了三年，从未还原过，数据库挂了后发现文件已经损坏，因为磁盘有坏道。从那以后，我每次都会提醒：备份不测试，等于没备份。
再聊聊备份速度问题。大库备份时， mysqldump 是单线程的，速度很慢， 100 GB 的库可能要跑几个小时。这时可以考虑分库分表备份，例如用 --databases 指定多个库，或 --tables 指定多个表，然后并行执行。比如有 10 个库，可以写脚本让每个库单独启动一个 mysqldump 进程，同时跑，速度能提升数倍。但要注意并发数，别把服务器 CPU 打满。还有一种更高效的工具是 mydumper，它是多线程的，备份速度比 mysqldump 快 3‑5 倍，还原速度也更快。不过 mydumper 的兼容性不如 mysqldump，某些特殊字符或函数可能报错。所以小库用 mysqldump， 大库用 mydumper，配合使用最靠谱。
说个很多人忽略的点：备份文件的完整性校验。 mysqldump 导出的 SQL 文件如果直接用 mysql 还原，它不会检查数据是否完整。万一网络传输丢包，或者磁盘写入出错，恢复出来的数据就不完整。我建议备份完成后，用 md5sum 或 sha256sum 生成校验值，存到另一个文件里。还原前先校验，校验不匹配就重新备份。备份文件最好按日期命名，例如 backup20240101.sql.gz，写个脚本定期清理旧备份，保留最近 30 天的。别让备份文件把磁盘占满，到了需要新备份时连空间都没有。
说一千道一万， mysqldump 这个工具看似简单，用起来却充满细节。只有踩过坑，才能真正了解它的“坑”。但只要把每个参数弄明白，设计好备份策略，它就是数据库的第一道防线。别等到数据库挂了才想起备份，也别以为备份了就万事大吉。定期做还原测试，检查备份文件的完整性，这才是靠谱的做法。毕竟，数据这东西，丢了就是丢了，哭都哭不回来。
