半夜两点，手机嗡嗡震个不停。我眯着眼摸到手机，屏幕上跳出运维群里的红色感叹号：“线上订单库挂了，InnoDB报错，直接起不来了。”那一瞬间，我整个人从床上弹起来，比喝了三杯浓缩咖啡还清醒。这场景，干过几年后端的人都不会陌生——数据库损坏这事，就像家里水管爆了，你明明知道它可能发生，但真砸到你头上的时候，还是慌得手足无措。
说实话，数据库损坏的原因五花八门，但常见的就那么几类：服务器突然断电、磁盘写满、硬件坏道、MySQL或者PostgreSQL的进程被强杀，还有那些操作失误，比如误删了表空间文件。症状也各有各的演法，有的直接拒绝启动，报错信息糊你一脸；有的表面上正常，但查询特定表的时候就报错；还有更阴的，数据读出来是乱码，或者主键冲突一堆。但不管哪种，第一步永远是同一个动作：别瞎折腾，先停下来。
我见过太多人，一看到数据库起不来，第一反应就是重启。重启没用，再重启。实在不行，把数据目录里的文件挨个翻一遍，这个删删那个改改。结果呢？本来可能只是个索引文件坏了，被他这么一搞，数据文件也对不上了，恢复难度直接翻倍。所以，第一步不是修复，是止损。你要做的第一件事，是立刻把数据目录完整地复制一份出来，哪怕用cp -r或者tar打包都行，放到另一块磁盘上去。为什么？因为你接下来所有操作都有风险，原文件一旦被二次破坏，神仙也救不回来。备份这步，就是给自己留条后路。
备份做完，第二步才是真正开始诊断。数据库起不来，报错日志是最直接的线索。MySQL的error log在数据目录下的hostname.err，PostgreSQL在pglog或者log目录里。打开日志，重点看几十行，那里通常藏着真正的崩溃原因。比如MySQL常见的报错“Table './dbname/tablename' is marked as crashed”，这说明表文件损坏了，修复方向就很明确。如果是“InnoDB: Corruption in the InnoDB redo log”，那问题出在redo log上，处理方式完全不一样。这就像医生看病，你得先搞清楚是感冒还是肺炎，才能开药。
诊断清楚了，第三步就是动手修。这里要分两种情况：MyISAM引擎的表和InnoDB引擎的表，修复手段不一样。MyISAM的表损坏，MySQL自带的myisamchk工具就能处理。先停掉数据库服务，然后去数据目录下执行：myisamchk --recover --quick 表名.MYI。如果quick模式不行，去掉quick再跑一遍。这工具跟老中医似的，一般的小毛病，一把脉就能好。但InnoDB就麻烦多了，它是事务安全引擎，自带崩溃恢复机制，多数情况下你启动数据库，它会自动回滚未完成的事务，然后就好了。但要是redo log也坏了，那就得用innodbforcerecovery参数，从1到6逐级往上升，每升一级尝试启动一次，直到能起来。
这里有个坑要提醒你，innodbforcerecovery设得越高，数据库能做的事就越少，比如6级的时候，InnoDB只做只读操作，很多查询都跑不了。所以这个参数是应急用的，起来之后的第一件事，是赶紧把数据用mysqldump导出来，然后重建一个新的数据库实例，把数据导回去。千万别想着在forcerecovery模式下长期运行，那相当于拄着拐杖跑马拉松，迟早出大事。
除了这两种常见情况，还有些更刁钻的场景。比如你用的是PostgreSQL，数据文件因为磁盘坏道出现了物理损坏，那pg_resetwal这个工具可能能帮你强制重置WAL日志，让数据库重新启动。但代价是，最近一段时间的事务会丢失，而且如果做不好，数据一致性也会出问题。这种时候，你就得权衡了：是丢最近几分钟的数据，还是让整个库彻底瘫痪。成年人的世界，没有两全其美，只有权衡取舍。
另外说一句，现在的云数据库，比如阿里云RDS、腾讯云TDSQL，它们通常自带高可用和自动备份功能。如果用的是云上托管实例，遇到损坏，最省事的方案是直接回滚到最近的备份时间点，或者用PITR（时间点恢复）功能恢复到某个具体时刻。但前提是，你之前开了备份功能，并且设置了合理的备份周期。很多人觉得开了自动备份就万事大吉，结果发现备份文件损坏或者备份策略覆盖范围太短，真到用的时候，傻眼了。
文章写到这里，你可能觉得修复流程也就那么回事。但我想说的是，数据库损坏这件事，真正考验人的不是技术，而是心态和预案。技术方案网上搜一搜，Stack Overflow上都有答案，但你能不能冷静下来，按步骤操作，不病急乱投医，这才是关键。我见过一个运维老哥，数据库崩溃后，他花了半小时确认了备份完好，然后悠闲地泡了杯茶，跟领导汇报说“预计两小时后恢复”，那种从容不是天生的，是提前演练过的底气。
所以，别真等到数据库坏了才想起来“三步修复法”。平时就要做好三件事：第一，定期备份，并且定期检查备份能不能用，别备份完就扔一边，那叫心理安慰；第二，写一份数据库故障恢复手册，把常见的崩溃场景、诊断命令、恢复步骤都写清楚，打印出来放工位上，或者存到手机里；第三，每半年搞一次故障演练，故意把数据库弄坏，然后按手册恢复，确保流程跑得通。这三件事，比任何修复技巧都重要。
数据库损坏这事，就像人感冒发烧，你没法保证一辈子不遇到，但你可以保证遇到的时候不慌。记住那个最朴素的道理：备份是爹，恢复是爷，平时多磕头，用时少流血。下次真碰上数据库起不来，深呼吸，按这三步走：先备份，再诊断，后修复。你会发现，大部分问题，其实并没有想象中那么可怕。
