前两天，一个朋友半夜打电话给我，声音都快哭了：“我数据库里的订单表全没了，客户数据丢了三天，怎么办啊！”这事搁谁身上都得慌。他的 MySQL 数据库用的是 InnoDB 引擎，平时也没做备份，就靠一个 binlog 在撑。我问他 binlog 开没开，他说开了，但不知道怎么用。我赶紧远程连上去一看，还好 binlog 文件在，只是已经被覆盖了一部分。情况听着吓人，但其实有救。MySQL 恢复这事，说复杂真复杂，说简单也简单，关键在于你手里握住了哪些“牌”。binlog、redo log、undo log 这些日志文件就是救命稻草。很多人以为数据库恢复是高深技术，其实核心只有一点：你把数据写进去时系统记了什么，咱就能捞回什么。
先聊最常见的场景——误删数据。比如手滑执行了 ，结果条件写错了，整表数据都被清空。这时别慌，第一步是立刻停掉所有写入操作，包括应用程序和定时任务。为什么？因为 InnoDB 的 undo log 里存着旧数据，一旦有新的事务提交，这些旧记录就可能被清理掉，恢复窗口期只有几分钟到几小时。如果 binlog 是 ROW 模式，恢复就更简单了。可以用 把 binlog 解析成 SQL，找到误操作之前的位点，然后回放。例如：前提是要知道准确的位点，这需要事先查看 binlog 内容，定位到“罪魁祸首”的那条 SQL。
但现实往往更残酷。很多人连 binlog 都没开，或者开了却没定期备份。这时 InnoDB 的 redo log 成了唯一防线。redo log 是循环写的，默认大小一般只有 48 MB，这意味着数据量一上来，几分钟前的记录就会被覆盖。所以一旦发现数据丢失，立刻停掉 MySQL 服务，千万别重启。重启会导致 redo log 被清空，届时只能靠备份了。可以使用 参数启动数据库，设置 1 到 6 的不同级别，绕过损坏的数据页。比如设为 1，会忽略检查点错误，但可能丢失部分事务；设为 6，会忽略所有错误，但数据一致性无法保证。这招是救命的，但不是长久之计，捞出数据后要尽快导入新库。
说到备份，这才是数据库恢复的王道。我见过太多人觉得“数据库跑得好好的，备份啥啊”，结果一出事就傻眼。MySQL 的备份策略其实很简单：全量备份加增量备份。全量备份可以用 或者物理备份工具 XtraBackup，按天或按周执行一次。增量备份依靠 binlog，把 binlog 按时间或大小切分，定时归档。恢复时，先恢复全量备份，再应用增量 binlog。比如周一做了全量备份，周三丢了数据，就先恢复周一的备份，然后从周一的 binlog 位点开始，一直应用到出事前的那一刻。操作听起来复杂，但写个脚本就能自动化，例如：关键是 binlog 不能断档，一旦缺少中间文件，后面的数据就接不上了。
还有一种让人抓狂的情况——硬件故障。比如磁盘坏了，或者 MySQL 的数据文件被意外删除。这时物理恢复比逻辑恢复更靠谱。物理恢复直接操作数据文件，如 文件。InnoDB 的每个表对应一个 文件，如果有完整的数据目录备份，只需把文件拷贝回去即可。但要注意，需要配合表结构文件 或者数据字典。如果使用 MySQL 8.0 以上版本，数据字典已经集成在 InnoDB 中，恢复会更麻烦，因为表结构信息也存储在 文件里。这时可以用 工具提取表结构，或手动重建表。我的一个客户磁盘阵列坏了，数据文件全丢，但他们每天用 XtraBackup 做物理备份。我们把备份拷贝到新服务器，执行 恢复一致性后启动 MySQL，数据全部恢复，耗时不到一小时。
最让人头疼的，其实是“看起来没丢，但数据不一致”的情况。比如执行了 ，结果更新错了，想回滚。这时 InnoDB 的 undo log 派上用场。事务隔离级别依赖 undo log，它记录了修改前的版本。如果事务还未提交，直接执行 就能恢复。但如果已经提交，undo log 就帮不上忙，只能靠 binlog。一个小技巧是：在执行高危操作前，先开启事务，用 或 ，确认无误后再 。万一出错，直接 就能恢复。很多人图省事，直接执行 或 ，不使用事务，这就是给自己埋雷。
还有一类情况不是手误，而是被攻击。比如勒索病毒加密了数据库文件，或黑客删掉了表。这时常规恢复手段基本无效，因为文件本身已经被破坏。能做的只有两点：一是查看是否有异地备份，如云存储或另一台服务器上的备份文件；二是检查数据库是否开启了 或 ，这些日志可能记录了攻击者的操作，但基本无法用于数据恢复。因此，防患于未然比事后补救更重要。建议所有 MySQL 用户做到三件事：第一，开启 binlog，并把 设置为 7 天以上；第二，每天做全量备份，保存到不同的物理位置；第三，定期演练恢复流程，确保备份文件可用。
说一个反常识的观点：数据库恢复不是技术问题，而是管理问题。我见过太多公司，技术团队配置了完善的备份策略，但管理层觉得“没必要”，结果数据丢了才后悔。或者技术团队自己懒，备份脚本写好了却没跑，跑了也没检查结果。MySQL 恢复这行当里，真正的高手不是会写复杂 SQL 的人，而是能提前预判风险、把恢复流程做成自动化的人。你花一天时间配好备份脚本，可能一辈子都用不上，但一旦用上，它就是救命稻草。所以别等到半夜接到电话才慌，今天就去检查一下 binlog 是否开启，备份是否完成，恢复流程是否跑通。数据库平时看似死水一潭，底下却是活火山。提前修好逃生通道，它才不会在你最需要时把你烧得只剩渣。
