数据库崩了，数据丢了，这大概是每个跟数据库打交道的人最怕遇到的噩梦。我见过太多人，凌晨三点盯着黑屏的终端，手心冒汗，脑子里一片空白。别慌，数据库损坏这事儿，其实比你想象中常见得多。硬盘坏道、内存错误、突然断电，甚至一个手滑的DELETE语句，都能把表搞成一团乱麻。但好消息是，大多数情况下，数据并不是彻底没了，只是藏得太深，需要点技巧才能翻出来。
我接触过的案例里，最让人头疼的不是物理损坏，而是逻辑损坏。比如一个事务写到一半崩了，索引文件跟数据文件对不上号，这时候你直接启动数据库，大概率会报错说“表不存在”或者“文件格式错误”。其实数据块还在磁盘上躺着，只是数据库自己都不知道该怎么读它们了。这时候千万别急着重装系统，更别格式化硬盘——很多数据修复专家最怕的就是用户“帮倒忙”，本来还能抢救，一格式化，神仙都救不回来。
第一种方案，也是最基础的，就是用数据库自带的修复工具。MySQL有myisamchk和mysqlcheck，PostgreSQL有pgresetwal和pgrewind，SQLite有.shell命令。这些工具本质上是“硬着头皮读数据”，遇到错误就跳过，能读多少算多少。比如MySQL的InnoDB引擎，你可以设置innodbforcerecovery参数，从1到6，数字越大，跳过的检查越多，但丢失的数据也可能越多。我一般建议先设成1，试试能不能启动，不行再往上加。但记住，这个参数只是应急，修完数据后一定要改回来，否则数据库会一直处于“半残”状态。
第二种方案，是从备份里恢复。很多人觉得备份就是定期导个SQL文件，其实远远不够。一个靠谱的备份策略，得包含全量备份、增量备份和Binlog日志。比如你用xtrabackup做全量备份，再用mysqlbinlog恢复最近几小时的数据，基本上能回到崩溃前几秒的状态。我见过最惨的案例，是某公司每天凌晨做一次全量备份，结果下午三点崩了，备份文件是昨晚的，等于丢了十几个小时的数据。后来他们加了每小时的增量备份和实时的Binlog同步，再碰到类似问题，最多丢几秒的数据。所以，备份不是“有就行”，而是“够用才行”——你得算清楚，业务能接受丢多久的数据。
第三种方案，是找专业的数据恢复工具或服务。如果你没有备份，自带的工具也救不回来，那就得靠第三方工具了。比如针对MySQL的Percona Data Recovery Tool，针对PostgreSQL的pg_recovery，或者针对SQLite的sqlite-recover。这些工具的原理是直接扫描磁盘上的数据页，绕过数据库的校验机制，把能读到的数据块拼起来。我有个朋友，公司数据库硬盘挂了，找某恢复公司报价两万，他觉得贵，自己用开源工具折腾了两天，居然把90%的数据救回来了。当然，如果数据太重要，或者损坏程度太严重，该花钱还是得花——专业公司的成功率确实更高，但前提是别再自己瞎操作了。
说到具体操作，其实有个顺序问题。先别急着用第三方工具，因为那些工具往往需要停掉数据库服务，甚至要卸载原来的实例。第一步，先看数据库能不能启动，哪怕启动后处于只读状态也好。第二步，如果有备份，优先用备份恢复，然后对比丢失的数据范围，看能不能用Binlog补回来。第三步，如果以上都不行，再把数据库文件拷贝出来，用第三方工具扫描。注意，千万别在原文件上直接跑修复，万一修坏了，连原始数据都丢了。我习惯的做法是：先做一份完整的磁盘镜像，然后在这个镜像上操作，这样就算搞砸了，还能从头再来。
还有个小细节，很多人容易忽略——日志文件。数据库的redo log、undo log、Binlog，这些文件里往往藏着修复的关键线索。比如MySQL的redo log里记录了最近的事务提交状态，如果数据库是意外宕机，redo log里可能还有没来得及写入数据文件的提交记录。这时候你启动数据库，它会自动回放redo log，把数据恢复到崩溃前一刻。但如果你手贱把redo log文件删了，那就只能靠其他方法了。所以，碰上数据库崩溃，第一时间不是重启，而是先检查日志文件是否完整。
再说个真实案例。去年有个做电商的朋友，他们的MySQL数据库突然报错“Table ‘orders’ is marked as crashed and should be repaired”。他试着用mysqlcheck修，结果越修越乱，表直接打不开了。我让他先停掉数据库服务，把数据目录下的所有文件备份一份，然后用Percona的恢复工具扫描。扫描出来的数据块里，大部分行都是完整的，只是少了几个字段的值。他手动补了这些字段，恢复了99%的订单数据。整个过程中，最耗时的不是工具扫描，而是手动检查那些“半残”的数据行——你得判断哪些数据能用，哪些得丢掉。
想说，修复数据库这件事，本质上是个“取舍”的过程。没有任何方案能保证100%恢复，因为损坏的程度上限你根本不知道。你能做的，就是手里多备几把刀——备份、工具、日志，一样都不能少。而且最好在业务低峰期做恢复操作，不然你的用户会跟着一起崩溃。记住，数据恢复的黄金法则是：别慌，别瞎动，先备份，再动手。
