上周一个做电商的朋友半夜给我打电话，说数据库挂了，网站直接白屏。他登录服务器一看，MySQL报错，数据文件打不开，后台一堆InnoDB相关的错误日志。他当时就慌了，问我有没有办法把数据捞回来。
说实话，干这行十几年，我见过太多类似的情况。数据库文件损坏这事，说大不大说小不小，处理得当就是虚惊一场，处理不当就是数据丢失的事故。关键是别慌，更别手贱去瞎操作。今天我就把这几年的实战经验整理成三步，你照着做，大概率能把损失降到最低。
第一步，先别急着重启，赶紧备份现场。很多人一看到MySQL连不上，第一反应就是service mysqld restart，这个动作在文件损坏的场景下特别危险。因为MySQL在启动时会尝试恢复，如果损坏的是系统表空间或者redo log，强制启动可能会覆盖掉原本还有救的数据页。正确做法是，先把整个数据目录复制一份，用cp -a或者rsync都行，确保原样保留。如果你用的是云盘，打个快照更是稳上加稳。备份完现场，再去诊断问题，这时候你才有试错的资本。
备份完现场，第二步就是分析损坏的类型。MySQL文件损坏分好几种，最常见的是表级损坏，也就是某个.ibd文件或者.MYD文件坏了，这种情况通常不影响其他表。你可以在配置文件里加上innodbforcerecovery参数，从1开始逐步往上调。这个参数的作用是跳过InnoDB在启动时的一些检查步骤，比如1是跳过崩溃恢复，2是跳过回滚段检查，3是跳过一些日志应用，最高到6。每调一档就尝试启动一次，能启动就说明问题定位在那个层面了。不过要记住，这个参数只能用来救数据，不能长期开着，否则数据库运行在非正常模式下，容易产生更多问题。
如果innodbforcerecovery能启动，那恭喜你，数据大概率能救回来。这时候你要做的就是用mysqldump把数据导出来，然后重建数据库。具体操作是，先用当前模式启动MySQL，然后用mysqldump把每个库每个表都导成SQL文件，再停掉MySQL，把数据目录整个清掉，重新初始化，把SQL文件导回去。这个过程看起来繁琐，但胜在干净彻底，相当于把坏掉的房子拆了重建，里面家具电器都搬出来了，总比在危房里凑合住要强。
但有时候情况更糟糕，innodbforcerecovery调到6都启动不了，或者能启动但mysqldump导出时报错，说明文件损坏程度比较深。这时候就得用更底层的工具了，比如Percona Data Recovery Tool for InnoDB，或者用strings命令直接从.ibd文件里捞数据。strings这个命令很土，但有时候真管用，它能把二进制文件里的可读字符串提取出来，如果你的数据是纯文本格式，比如VARCHAR类型，那就能捞出一部分。我之前帮一个客户处理过，他一个文章表的content字段，就是用strings捞回来的，虽然格式乱了点，但内容都还在，总比什么都没有强。
第三步，也是很多人容易忽略的一步，就是恢复完数据之后，一定要做验证。别以为导出来就算完事了，你得检查数据完整性，比如行数对不对，主键有没有重复，关键字段有没有缺失。我见过有人辛辛苦苦把数据导出来，结果导入新库后发现有几千条记录是坏的，业务跑起来各种报错，回头还得重新处理。验证的方法很简单，用SQL跑几个count和sum，和业务方的报表对一下，或者抽查几条关键记录，看看字段值是否合理。确认没问题，再切换上线，这一步省不得。
说完了三步操作，我再补充几个日常预防的点。第一，备份一定要做，而且要定期做，最好是全备加binlog，这样即使数据文件全毁了，也能通过binlog恢复到最近的时间点。第二，磁盘空间要监控，很多时候文件损坏就是因为磁盘满了，MySQL强制写入导致页损坏。第三，硬件问题要留意，尤其是内存和硬盘，我用过的案例里，有一半以上是内存条坏了导致数据写错，或者硬盘有坏道导致读取失败。定期跑一跑badblocks或者smartctl，能提前发现问题。
说点掏心窝的话。数据文件损坏这事，其实没那么可怕，可怕的是没有准备，没有预案。你平时多花半小时做一次备份，关键时刻就能省下好几天的痛苦。我那个做电商的朋友，后来按照我说的步骤，用innodbforcerecovery=2把库拉起来了，mysqldump导出后重建，整个恢复过程也就花了两小时，丢失的数据不超过十分钟的业务量。他后来说，再也不敢不备份了。
所以，记住这三步：先备份现场，再分析损坏类型，验证数据完整性。遇到问题别慌，按步骤来，你的数据大概率能完好无损地回来。
