那天半夜两点，我一个朋友打来电话，声音颤抖地说公司数据库崩了，几万条客户数据全没了。我问他有没有备份，他说备份是做了，但不知道怎么恢复。电话那头传来键盘声，他同事正对着 MySQL 的命令行发愣。这场景我太熟悉了，干这行的谁没经历过几次“删库跑路”的惊魂时刻？MySQL 恢复数据库这事儿，说难不难，说简单也不简单，关键在于你知不知道那几个核心命令，以及在慌乱时如何不出错。
先说最基础的恢复方式：用 MySQL 命令行直接导入 SQL 文件。很多新手以为恢复就是把备份文件扔进数据库就行，结果一执行就报错。正确的姿势是：先登录 MySQL，创建一个空数据库，然后用 命令导入。比如有个备份文件叫 ，先执行 ，再 ，最后 。这里有个坑，很多人在执行 时不写绝对路径，导致找不到文件。我习惯把备份文件放在 MySQL 的 data 目录下，或者直接写在根目录，省得路径搞错。另外，如果备份文件特别大，几十 GB 那种，建议用 这种管道导入方式，效率高得多。导入前记得检查文件完整性，用 看看表结构语句的数量是否正常，别等跑了一半才发现文件损坏。
再说物理恢复，也就是直接恢复数据文件。这种情况通常发生在服务器崩溃、系统重装的时候。MySQL 的数据文件默认存放在 目录下，每个数据库对应一个文件夹。恢复时，只需要把备份的数据库文件夹复制回去，然后重启 MySQL 服务。但这里有个致命细节：文件权限。我之前帮一个客户恢复数据库，文件明明复制进去了，却被 MySQL 不认。查了半天，原来是文件所有者是 ，而 MySQL 进程是用 用户运行的。执行 后，问题立马解决。另外，如果遇到表损坏的情况，可以在配置文件中加上 ，让 MySQL 以恢复模式启动，跳过损坏的页面，先把能读的数据导出来。这个参数可以设 1 到 6，数字越大越“暴力”，风险也越高，建议从 1 开始尝试。
说到备份策略，很多人以为只要每天跑一次 就万事大吉。实际上，恢复的成功率往往取决于备份的颗粒度。举个例子，如果使用 的默认参数，备份文件里会包含大量锁表语句，恢复时会导致长时间等待。我常用的命令是 最关键，它能在不锁表的情况下获取一致性快照，对 InnoDB 引擎尤其友好。如果数据库特别大，还可以加上 条件只备份最近一周的数据，或者用 跳过日志表。恢复时，记得先在目标库上执行这两条可以大幅提升导入速度。我曾经把一个 20 GB 的备份，关掉这两个检查后，恢复时间从 4 小时缩短到 40 分钟。
增量恢复是另一个让人头疼的领域。如果启用了 MySQL 的 binlog，理论上可以恢复到任意时间点。但实际操作中，很多人因为搞不清 binlog 的顺序，恢复出来的数据反而是乱的。正确的做法是：找到全量备份时对应的 binlog 位置，然后用 解析日志，只提取全量备份之后到崩溃之前的那段。例如全量备份在凌晨 2 点，系统在下午 3 点崩溃，可以这样导出增量数据：再导入到全量恢复后的数据库中。这里有个容易踩的坑：binlog 里可能包含误操作的 语句。如果要恢复被误删的表，需要在解析时加上 或者用 过滤掉那条语句。实在不行，可以加上 参数，把日志转换成可读的 SQL，手动删除危险语句。
跨版本恢复这件事我吃过不少亏。MySQL 从 5.7 升级到 8.0 后，数据文件格式变了，直接复制 data 目录会报错。跨版本恢复最稳妥的方法是：在旧版本上用 导出 SQL 文件，然后在新版本上导入。但要注意字符集问题，尤其是 5.5 升级到 5.7 时，默认字符集从 latin1 变成了 utf8mb4，导出的 SQL 文件里如果有特殊字符，导入时会报错。我的习惯是在导出时指定字符集：导入时同样指定字符集。如果仍然报错，可以用 批量替换 SQL 文件中的字符集声明。跨大版本恢复时，最好先在测试环境跑一遍，因为有些语法在旧版本能用，新版本已废弃，例如 在 MySQL 8.0 已不支持。
说点血的教训。去年有个创业公司找我救急，他们的数据库被勒索病毒加密，连备份文件也没逃过。只能从云服务商的快照里恢复，但快照是三天前的，导致三天的数据全丢失。这件事让我养成了一个习惯：备份文件要存三个地方——本地一份、云存储一份、异地硬盘一份。而且每次恢复前，都要做一次测试恢复，确认备份文件完整。我写了个脚本，每周一凌晨全量备份，每 6 小时增量备份，备份完成后自动在测试库上执行恢复并对比行数。如果发现不一致，立刻发邮件报警。这套流程跑了两年，救过我好几次。记住，数据库恢复不是靠运气，而是靠预案。你花在备份和恢复策略上的每一分钟，灾难来临时都会变成救命稻草。现在，去检查一下你的备份文件还能不能用吧。
