聊数据库备份，绕不开的就是mysqldump。这个命令行工具，像老朋友一样，陪着我们走了二十多年。它没那么多花架子，就是朴实无华地把MySQL数据库里的逻辑数据，一条一条导出成SQL语句。你想想，当你半夜被电话吵醒，说数据库崩了，手头没有热备，没有主从，连个备份镜像都没有——这时候，如果电脑里还躺着一份昨天crontab自动跑的mysqldump备份，那感觉，简直就像抓住了救命稻草。虽然现在云原生、备份恢复工具层出不穷，但mysqldump依然是很多人接触数据库备份的第一个技能，也是一根稻草。
说到备份，很多人上来就敲一行“mysqldump -u root -p databasename > backup.sql”，然后觉得万事大吉。其实，这里面门道很深。比如，你导出的是全量数据，但MySQL版本不一样，导入的时候就可能报错。我曾经在一个项目里，从MySQL 5.7导出，导入到5.6的库，结果因为字符集和语法差异，直接卡死在半路。所以，备份前最好先确认目标环境。mysqldump有个参数叫--compatible，能指定兼容模式，比如兼容oracle或者mysql40，但说实话，最靠谱的还是同版本迁移。另外，--single-transaction参数一定要带上，它能在不加锁的情况下，通过开启一个事务来保证数据一致性。如果你不写这个，备份大表的时候，整个库可能被锁住，线上业务直接停摆。
再说说还原。很多人以为还原就是“mysql -u root -p databasename < backup.sql”，敲完回车就完事。实际上，还原过程中最怕的是“半路翻车”。比如，备份文件有10GB，你直接往生产库里灌，一旦中间网络断了或者内存不够，导入到一半就挂了。这时候数据库里既有新数据，又有老数据，乱成一锅粥。我的习惯是，先建一个临时库，把备份导进去，检查数据行数、表结构是否完整，再切到正式库。如果是超大库，最好用mysql的source命令，还能盯着进度条看，不至于傻等。另外，还原前一定要关闭二进制日志，不然导进去的数据会写binlog，导致日志暴增，磁盘撑爆。还原完记得再手动开回来。
备份策略也是个讲究活儿。很多新手喜欢每天凌晨全量备份一次，觉得够了。但实际上，如果数据库每天写入量大，全量备份不仅耗时长，还占磁盘。更合理的做法是：每周一次全量备份，每天一次增量备份。mysqldump虽然不支持真正的增量备份，但你可以配合二进制日志实现。具体来说，先mysqldump全量导出，记录下当前binlog的位置，然后每天用mysqlbinlog工具解析增量binlog。这样，即使某天出问题，你只需要恢复全量备份，再重放增量日志，就能回到故障前那一刻。当然，这需要点脚本能力，但为了数据安全，这点功夫值得花。
备份文件的管理同样不能马虎。我见过太多人把备份文件直接扔在数据库服务器的/root目录下，结果磁盘满了，谁也进不去。更可怕的是，服务器被黑了，备份文件也跟着一起被删。所以，备份文件一定要异地存储，比如通过rsync同步到另一台机器，或者上传到对象存储。另外，文件命名要有规律，比如“dbname20231027.sql.gz”，带上日期和库名，方便查找。压缩也很重要，mysqldump默认输出文本，一个500MB的库，导出来可能2GB。用gzip压缩后，能缩小到200MB左右，传输和存储都轻松很多。记住，备份文件不是越多越好，要定期清理，保留最近7天或者30天的就够了。
还有个小细节，很多人会忽略：备份时的字符集问题。如果你的数据库用的是utf8mb4，但mysqldump默认用utf8导出，一些emoji表情或者特殊字符就会变成乱码。等到还原的时候，这些乱码数据会直接导致SQL执行错误。解决办法很简单，在导出时加上--default-character-set=utf8mb4参数，确保和库的字符集一致。同样，导入的时候也要指定同样的字符集。另外，如果你备份的是存储过程、函数、事件，别忘了加上--routines和--events参数，否则这些对象不会出现在备份文件里。等到还原完，发现所有存储过程都没了，那才叫一个头大。
我想聊聊心态问题。很多开发者觉得备份是运维的事，自己只管写代码。但实际上，数据库备份是每个人的底线思维。你想想，如果某天你手误删了表，或者上线脚本跑错了，数据没了，你找谁哭？mysqldump虽然看起来笨拙，但它不依赖复杂的架构，一台机器，一个命令，就能给你一个完整的逻辑备份。它像消防栓，平时你嫌它碍眼，但真着火的时候，它就是你唯一的。所以，别嫌麻烦，把这个基础技能练扎实了，写个自动化脚本，每天凌晨自动备份，自动压缩，自动上传到远程。做到这一步，你才算对得起自己写的每一行代码。
