我干数据库运维这些年，最怕半夜接到电话。对方语气急促，说数据库挂了、数据丢了。MySQL 崩了、表被误删、数据被覆盖，每种情况都足以让人血压飙升。但说实话，只要平时做好了备份，或者配置得当，绝大多数情况下都能把数据捞回来。今天就把我这些年积累的恢复经验，掰开揉碎地讲给你听。
先说最常用的一招：用 mysqldump 备份的文件恢复数据。这是最稳妥的方式，前提是你得有备份。很多公司把备份脚本写进 crontab，每天凌晨跑一次，但问题往往出在恢复这一步。比如你有个叫 testdb 的库，备份文件是 testdb.sql，恢复命令其实就一行：。注意，这里要确保目标库已经存在，如果库被删了，得先 。更坑的是，有人备份时忘了加 参数，导致恢复时没有建库语句，数据直接往当前库塞，表会跑偏。所以建议备份时养成习惯，使用 ，这样恢复时自带建库语句，省心多了。
再说物理备份恢复，也就是直接拷贝数据目录。这个方法在数据量大、恢复时间紧的时候特别好使。MySQL 的数据文件默认在 ，每个库对应一个文件夹，每个表对应 和 文件。恢复时先停掉 MySQL 服务，把备份的文件夹整体拷回去，修改好权限，再启动服务。但这里有个坑：MySQL 版本必须一致，5.7 的数据文件拷到 8.0 上，大概率启动失败。还有，如果表使用 InnoDB 引擎，还得确保 这个系统表空间文件也同步恢复，否则数据会为空。我见过有人只拷了库文件夹，忘了拷 ，结果启动后表结构能看到，数据却全是空的。
说个真实案例。有次同事误执行了 ，整个人都懵了。我赶紧查 binlog，也就是二进制日志，这是 MySQL 用来记录所有写操作的。只要 binlog 功能开着（一般生产环境都会开），就能把数据恢复到删除前的任意时间点。先找到 binlog 文件的位置，用 工具解析成 SQL：。然后在这个 SQL 文件里，找到 那行之前的内容，截取出来执行。如果数据量太大，可以用 参数指定截止时间，精确到秒。例如：。这样就能跳过删除操作，把之前的数据全部恢复。
还有一种更惊险的情况：表被 了。 和 不一样，它不会逐行记录 binlog，而是直接重置表空间。但别慌，如果是 5.6 以上版本，开启了 GTID 模式，可以用 工具从从库同步回来。如果没有从库，只能靠全量备份加 binlog 增量恢复。先恢复最近一次全量备份，然后用 恢复从备份时间点到 之前的所有增量数据。这里有个细节：全量备份恢复后，先记录下备份时的 binlog 位置，例如 。随后执行 ，即可无缝衔接。
说到从库恢复，这是很多公司忽略的救命稻草。主库挂了，从库还在，直接提升从库为主库就行。但更多场景是主库数据被误删，从库同步也跟着遭殃。这时可以在某个时间点，从从库拉一份数据出来。如果从库开启了 并行复制，数据可能不一致，得先 ，等所有线程处理完，再 。或者更狠一点，直接物理拷贝从库的数据目录到主库，但记得要重置主从关系。我见过最骚的操作是有人用 比对主从数据，然后用 修复差异，硬是把误删的数据从从库捞了回来。
说几个日常防坑的硬道理。第一，备份文件别放在 MySQL 服务器本地，硬盘坏了全玩完，应该放到对象存储或远程 NAS 上。第二，定期做恢复演练，别等到真出事才发现备份文件损坏。第三，binlog 保留周期别设太短，至少保留 7 天，生产环境建议 30 天。第四，使用 MySQL 8.0 时，可以开启 Clone 插件，做物理克隆备份，恢复速度比 mysqldump 快一个量级。第五，所有操作先在测试环境跑通，别在生产线上直接执行高危命令。记住一句话：数据恢复的核心不是技术多炫，而是准备多充分。备份做好，恢复就像喝凉水；备份没做好，那只能祈祷佛祖保佑了。
