前两天一个做电商的朋友半夜给我打电话，声音都变了调——他们公司的数据库突然崩了，几万条订单数据全乱套了。他说当时整个人都是懵的，脑子里嗡嗡响，客户订单、物流信息、库存记录全挤在一块儿，连最基本的查询都跑不动了。这种场景我听得太多了，干这行的都知道，数据库出问题不是“会不会”的问题，而是“什么时候”的问题。我让他先别慌，赶紧停掉所有写入操作，把数据库日志备份一份出来，然后开始排查崩溃的原因。他那边沉默了几秒，说了句让我后背发凉的话：“日志？我们没开日志。”
这事儿听着离谱，但真不是个例。很多中小公司管数据跟管仓库似的，觉得东西放进去就完了，从来不想着维护。他们不知道数据库就像个精密的钟表，零件多、运转快，任何一个齿轮出问题，整个系统就卡住了。那次我花了整整两天帮他恢复数据，用尽了各种手段，只捞回来七成左右。剩下的三成订单数据永远消失了，客户投诉电话打爆了公司座机，赔了不少钱才摆平。这哥们后来跟我说，那一周他头发白了一半，不是夸张，是真的一夜之间白了。
其实数据库崩掉的原因很常见，无非就那几类。硬件坏了，硬盘突然报废，服务器被雷劈了（真有这事儿），机房空调故障导致机器过热。软件层面的问题更多，写了一半的事务因为断电中断，导致数据文件损坏；操作系统突然蓝屏，数据库文件没来得及同步；或者就是人为操作失误，误删了表，跑了个错误的更新语句。我见过最夸张的一次，有个运维凌晨三点困得不行，在生产环境执行了一条delete不带where条件，直接把整个用户表清空了。那哥们后来被开除了，但数据没了就是没了。
很多人觉得数据库修复是技术活儿，交给DBA就行了。但问题在于，很多公司根本没有专业的DBA，甚至连个懂数据库的都没有。数据库是老板让装上的，日常维护就是“能用就行”。等到出事了才想起来找外援，这时候往往已经错过了最佳修复时机。我认识一个专门做数据恢复的朋友，他说他接的案子里面，有三分之一是因为出事之后胡乱操作把数据搞得更糟的。比如有人发现数据库坏了，第一反应是重装系统，结果把原始数据文件全覆盖了。还有人觉得重启能解决一切，结果数据库因为文件损坏根本起不来，反复重启把坏块越扩越大。
真正专业的修复流程，第一步永远是备份。不是备份现在的数据，而是备份损坏的数据。很多人不理解，说数据都坏了还备份什么？这就是外行话了。损坏的数据库文件里，大部分数据其实还是好的，只有少数区域出了问题。你要做的第一件事，就是把这份“坏的”文件完整地复制一份出来，然后所有操作都在副本上进行。这样万一修坏了，你还有机会从头再来。我见过太多人拿到损坏的数据库就往上怼，各种修复命令轮番上阵，把能救的数据也折腾没了。
接下来是判断损坏程度。不同级别的损坏，修复策略天差地别。轻度的损坏，可能只是某个索引文件出了点问题，重建一下索引就能恢复正常。中度的损坏，可能是数据页出现了坏块，需要用专门的工具把坏块标记出来，然后从备份中恢复这部分数据。严重的损坏，比如系统表损坏或者事务日志彻底挂了，那就得用上数据恢复软件，逐块扫描数据文件，尝试把能读出来的记录一条条捞出来。最极端的情况是磁盘物理损坏，这时候连操作系统都认不出硬盘了，需要找专业的数据恢复公司开盘处理，费用动辄几万甚至十几万。
但说实话，修复永远只是补救措施，不是常规操作。真正靠得住的方法只有两种：备份和容灾。备份这个东西，听起来老生常谈，但能做到的公司真不多。我见过很多公司的备份策略就是个笑话——备份文件和生产数据库放在同一个硬盘上，硬盘坏了大家一起完蛋。或者备份周期设成一个月一次，出问题的时候备份数据比当前数据还老，恢复完了客户订单都过期了。合格的备份至少要做到异地存储，每天全量备份加每小时增量备份，而且必须定期做恢复演练，确保备份文件真的能恢复成可用的数据库。
容灾就更高级一些，但也不是什么神秘的东西。简单说就是做一台备用数据库，主库写数据的同时，实时同步到备库。主库挂了，备库直接顶上，切换时间不超过一分钟。这种方案成本确实高一些，但和数据库崩溃导致的损失比起来，这点钱真不算什么。我那个做电商的朋友后来痛定思痛，花了几万块搭了一套主从架构，加上定期备份。他跟我算过一笔账，上次数据库崩溃造成的直接经济损失超过三十万，加上客户流失和品牌口碑的损失，少说五十万打底。几万块的容灾方案，相当于给公司买了个保险。
说到底，数据库修复这件事，本质上是技术问题，但根子上是管理问题。很多公司不重视数据资产，觉得数据就是一堆记录，丢了也无所谓。直到真丢了，才发现那些数据是公司的命根子。用户的信任、交易的凭证、系统的运转逻辑，全写在数据库里。修复技术再牛，也不如预防做得好。我见过太多人在数据库崩了之后才想起备份，在数据丢了之后才想起容灾，晚了，真的晚了。
