说真的，写这篇文章时，我脑子里第一个蹦出的场景是上周一个朋友半夜给我打电话，声音带着哭腔：“完了完了，公司数据库文件坏了，客户数据全没了！”我问他备份呢，他沉默了三秒，那种沉默比任何语言都让人绝望。这种情况，搞过数据库的人应该都不陌生——MySQL 文件损坏，要么是突然断电，要么是磁盘故障，要么是操作失误，反正就是文件打不开了。这时候第一反应千万别慌，也别随便在网上找个命令执行，搞不好会越修越坏。
先说说最常见的损坏情况，就是 MyISAM 存储引擎的表文件。该引擎在写入数据时不太爱做完整的事务日志，一旦系统崩溃，表文件就容易出现索引和数据错位。遇到这种情况，MySQL 自带的工具 mysqlcheck 完全可以派上用场。我见过太多人一上来就想用第三方工具，其实根本没必要。只要在命令行里敲 ，它就会自动修复损坏的索引和记录。 参数是 repair 的意思，会尝试重建索引，有时还能把数据捞回来。不过要注意，如果表特别大，修复时间会很长，千万别中途中断，否则可能彻底报废。
如果是 InnoDB 引擎的损坏，事情就复杂多了。InnoDB 现在用得最广，因为它支持事务和行级锁，但它的数据文件结构和 MyISAM 完全不同。InnoDB 的损坏通常分为两种：一种是系统表空间文件 ibdata1 坏了，另一种是每个表独立的 .ibd 文件出了问题。ibdata1 坏了，最直接的表现是 MySQL 启动不了，报 “InnoDB: Corruption in the InnoDB tablespace” 之类的错误。这时候别急着删文件，先把 参数设成 1 到 6 之间的值，例如在配置文件里加上 ，然后重启 MySQL。该参数的作用是让 InnoDB 跳过部分错误检查，强制启动。从 1 开始尝试，能启动就赶紧把数据导出来，导完再重建数据库。
说到强制启动，这里有个血泪教训：千万别为了省事直接设成 6。我见过一个案例，有人图省事设成 6，结果 MySQL 确实启动了，但所有数据都变成只读模式，任何写操作都会导致更严重的损坏。6 是最极端的值，会跳过几乎所有恢复检查，只适合在其它值都无效时尝试。而且一旦启动成功，必须立刻用 mysqldump 把数据全部导出。导出时最好一次性生成完整的 SQL 文件，别分表导出，因为有些表可能已经损坏到无法读取，只导能读的部分，剩下的数据只能靠日志或备份来补。
还有一种更让人抓狂的情况：单个 .ibd 文件损坏，但整个数据库还能启动。比如你发现某个表查询报错，其他表正常。这时可以先尝试 重建表结构，MySQL 会重新生成表空间文件。如果这一步失败，说明文件损坏很严重，就只能考虑使用第三方工具。市面上有个叫 Percona Data Recovery Tool for InnoDB 的开源工具，名字虽长，却真的能救急。它可以直接从损坏的 .ibd 文件里提取数据，生成 CSV 或 SQL 格式的输出。不过该工具对操作者要求较高，需要了解一些底层页结构的知识，提取出来的数据可能会有乱码或丢失，但总比什么都拿不回来强。
说一千道一万，修复永远是被动的选择，预防才是王道。我每次给团队培训都会强调一句话：“备份，备份，再备份，而且备份要能恢复。”很多人的备份只是每天跑个脚本把数据文件拷贝一份，却从未测试过恢复。等到真出事时，才发现备份文件已损坏，或者恢复出来的数据对不上。靠谱的备份策略应该是：每天做一次全量备份，每几小时做一次增量备份，而且每周要模拟一次灾难恢复演练。别觉得麻烦，一次恢复失败的成本，足够让你演练上百次。另外，开启 binlog 日志也很关键，它能帮助你恢复到某个时间点，而不是只能回到上次备份的状态。
我想说，数据库损坏不是“会不会发生”的问题，而是“什么时候会发生”的问题。就像我那个半夜打电话的朋友，他后来花了三天时间才把大部分数据恢复回来，但几张关键表的数据仍然丢失。那三天里他瘦了五斤，真的不是夸张，是真吃不下、睡不着。所以，如果你现在手里有项目在使用 MySQL，建议立刻做两件事：第一，检查你的备份策略，确保备份文件能够正常恢复；第二，给数据库加个监控系统，一旦出现异常读写或磁盘错误，能第一时间收到报警。别等到半夜被电话吵醒，才想起这篇文章。
