上周有个朋友半夜给我打电话，声音都快哭了——他那个创业公司跑了大半年的客户管理系统，突然崩了。数据库文件损坏，点开全是乱码，后台报错提示“数据库引擎无法访问”。他说那一刻脑子里只有一个念头：完了，全完了。
这种绝望我太懂了。干媒体这些年，见过、听过的数据灾难少说也有几十起。有人因为数据库崩溃，公司直接关门；有人花了上万元找数据恢复公司，结果只捞回一半数据；还有更惨的，备份和主库一起坏掉。说句扎心的话，数据库这东西，平时像个老实巴交的管家，一旦翻脸，就成了六亲不认的主。
先说说最常见的修复方法。如果你的数据库是 MySQL，而且只是表结构没坏，数据还在，可以试试用 mysqlcheck 工具。在命令行敲一句 “mysqlcheck -r 数据库名”，它会自动检查并修复损坏的表。这招对付索引损坏特别管用，成功率大概有七八成。我见过一个技术总监，凌晨三点用这招救回了公司近半年的订单数据。但要注意，它只适用于 MyISAM 引擎，InnoDB 引擎得用另外的命令。
InnoDB 引擎的修复要麻烦得多。需要把 innodbforcerecovery 参数设成 1 到 6 之间的数值，从 1 开始慢慢往上试。设成 1 时，MySQL 会跳过损坏的页，能读多少读多少；设到 6 时，就相当于让数据库“裸奔”——不管数据完整性，只管把数据吐出来。我认识的一个 DBA，曾把参数设到 4，硬是从一个完全打不开的库中拽出了 80% 的数据。但有个坑：参数设得越高，数据丢失的风险就越大。所以一定要先备份整个数据目录，万一搞砸了还能重来。
如果 MySQL 自带的工具救不了，还有第二招：用第三方修复软件。市面上比较靠谱的有 Stellar Repair for MySQL、SysTools MySQL Repair。这些工具的原理是直接解析 .frm 和 .ibd 文件，绕过数据库引擎的验证机制。我测试过几个，Stellar 那款成功率最高，能处理表头损坏、页损坏、甚至被病毒加密的数据库。不过价格不便宜，单次修复要几百块钱。而且要注意，这些工具只能修复文件层面的损坏，如果硬盘本身有坏道，还得先处理硬件问题。
说到硬件问题，就不得不提另一种情况：数据库文件还在，但硬盘读不出来。这时候千万别乱动，更别自己捣鼓磁盘修复工具。我见过最蠢的操作，是一个程序员发现硬盘有坏道后，用 chkdsk 强制修复，结果把数据库文件所在的扇区标记成坏块，数据直接没了。正确的做法是：先找一块同样容量的好硬盘，用 ddrescue 这种工具做磁盘镜像。它能跳过坏道读取好数据，速度慢但安全。镜像做好后，再在镜像盘上尝试修复，这一步能救回九成以上的数据。
还有一种情况比较隐蔽：数据库看起来正常，但查询某些数据就报错。这通常是索引损坏或数据页内部校验不一致。用 “CHECK TABLE” 命令能定位到具体哪个表、哪个索引出了问题。然后可以用 “REPAIR TABLE” 修复，或者在导出数据时加上 “--skip-errors” 参数，把能导出的数据先导出来。我处理过一个案例，一个论坛的帖子表有几十万条记录，其中三条数据页损坏。用这个办法，只丢了那三条帖子，其余的完好无损。
说了这么多技术手段，其实最重要的还是预防。我采访过的一个数据恢复专家，干了十五年，他说他经手的案例里，有六成都是因为备份策略有问题。要么是没有做备份，要么是备份文件早就损坏却没人发现。他给的建议特别简单实用：每天做一次全量备份，每四小时做一次增量备份，每周验证一次备份文件能否正常恢复。记住，备份不是做了就行，而是要确保它能用。
说句实在话：数据库修复这事儿，三分靠技术，七分靠运气。但运气只眷顾那些有准备的人。平时做好备份，出了问题保持冷静，先用最简单的方法尝试，不行再逐步升级方案。如果真的救不回来，也要想清楚：数据没了公司还能不能活？如果能，那就接受损失，重新开始；如果不能，那说明从一开始，你的商业模式就过于依赖那堆数据，而不是靠团队和产品。这个道理，比任何技术方案都重要。
