数据库出问题这事儿，干运维的谁没碰上过几回？凌晨三点被电话吵醒，那边业务方急得嗓子都劈了：“库连不上了！”你睡眼惺忪打开电脑，心跳跟着监控告警一起飙。这种时刻，手边要是没一套靠谱的修复思路，再好的技术底子也得慌神。所以我写这篇东西，不整虚的，全是在生产环境踩过坑、填过土之后攒下来的实操经验，你当个随身手册看就行。
先别急着敲命令，第一步永远是搞清楚故障类型。数据库修复最忌讳上来就动手，我见过太多人一慌就重启，结果把InnoDB的redo log搞乱，本来小问题硬拖成大事故。你得先看日志，MySQL的error log、PostgreSQL的pglog，还有系统层面的dmesg，每条报错都别放过。比如常见的“Table is marked as crashed”和“InnoDB: Corrupted page”，这俩的处理路径完全不同——前者用REPAIR TABLE就能搞定，后者可能得动ibd文件。还有种情况是磁盘满了或者文件权限变了，这种连修复都算不上，清理空间改个权限就完事，但你要是没诊断清楚就瞎折腾，反而把简单问题复杂化。
我自己的习惯是，接到告警先做三件事：看监控曲线、翻最近变更记录、查慢查询日志。监控能告诉你故障是突然发生的还是缓慢恶化的，变更记录能帮你锁定是不是有人改了配置或者动了表结构，慢查询日志则能暴露是不是有烂SQL把资源耗尽了。这三步走下来，故障原因基本能猜个八九不离十。要是还拿不准，那就用工具诊断，MySQL的mysqlcheck --check、PostgreSQL的pgamcheck，跑一遍能定位到具体哪张表哪个索引出了问题。记住，诊断阶段花的时间永远值得，它决定了你后面修复动作是精准打击还是盲人摸象。
说到具体修复手段，MyISAM表的损坏算是最常见的。这种表的修复方式很直接，先停掉对这个表的写入，然后跑REPAIR TABLE，轻量级损坏基本几秒钟就完事。要是REPAIR失败，就用myisamchk工具，记得先备份.frm和.MYD文件，然后myisamchk --recover --quick，再不行就--safe-recover，两个参数差别在于扫描深度和修复强度。我处理过最狠的一次，MyISAM表索引文件整个废了，数据文件还完好，这种情况你直接重建索引就行，不用动数据。但说句实在话，现在谁还在生产环境用MyISAM？这种修复技巧属于基本功，练练手可以，别指望它救大命。
InnoDB的修复才是重头戏。它跟MyISAM最大的区别是，数据存在共享表空间或者独立表空间里，而且有redo log和undo log两层保护机制。最常见的损坏场景是“Corrupted page”或者启动时报“InnoDB: Assertion failure”。这时候第一步不是修复，是备份数据目录，把整个datadir拷走，哪怕用cp -a也行。然后看innodbforcerecovery参数，这个参数从1到6，数字越大恢复力度越强但风险也越高。我一般从1开始试，能启动就赶紧用mysqldump把数据导出来。1不行就试2，但记住，forcerecovery=2及以上会跳过回滚操作，可能造成数据不一致，所以导完数据立刻重建实例才是正道。
还有个场景特别折磨人——主从复制坏了。从库报“SlaveSQLRunning: No”，错误码通常是1062（主键冲突）或者1032（找不到记录）。这玩意儿不修好，主库一挂你就是裸奔状态。处理思路是定位到具体出错的SQL，跳过它再继续，但跳之前得想清楚：是跳过一条就行，还是后续还有一堆类似的？如果错误信息明确说“Duplicate entry”，大概率是主库上改过数据没同步过来，你可以SET GLOBAL sqlslaveskipcounter = 1，然后START SLAVE。要是错误码是1032，说明主库删了记录但binlog没传全，这种得用pt-table-checksum和pt-table-sync工具来比对修复，别手抖直接跳过，不然数据对不上，后面业务会给你颜色看。
说到工具，Percona Toolkit这套东西真是救命稻草。pt-online-schema-change用来在线改表结构，pt-query-digest分析慢查询，但最实用的还是pt-table-sync，它能精准对比主从数据差异并生成修复SQL。我有个客户，他们的从库因为一次机房断电滞后了三天，主库上改了上万条记录，用pt-table-sync跑了一晚上，全部对齐，中间业务零感知。还有xtrabackup，做物理备份和恢复必备，它比mysqldump快太多，尤其大库场景，mysqldump导10G数据得半小时，xtrabackup十分钟搞定，而且恢复的时候能直接做增量合并。
文件系统层面的坑也得留个心眼。数据库跑在ext4上，突然断电或者内核panic，很容易出现文件系统不一致。这时候千万不能直接挂载然后启动数据库，你得先fsck，把文件系统修干净。我就遇过一次，同事急吼吼地mount上分区，结果InnoDB读到一半报“File ./ibdata1: 'aio write' returned OS error 122”，数据目录全废了，只能从备份恢复，白白丢了半天数据。另外，SSD的trim和数据库的page size不匹配也可能导致数据损坏，这种硬件层面的问题你光靠软件修复是治标不治本，得换盘或者调整挂载参数。
修复完之后，别急着宣布胜利，先做完整性校验。MySQL可以跑CHECK TABLE，PostgreSQL用pganalyze和pgverify_checksums，确保所有表结构、索引、外键都正常。然后启动应用，观察一段时间监控，看有没有异常报错。我通常会在修复完成后盯着看至少两个小时的慢查询和错误日志，确认没有隐藏问题。但更重要的，是复盘这次事故的根因。是磁盘空间没监控？是备份策略不完善？还是代码里有烂SQL导致锁竞争？不把根因揪出来，下次还得半夜爬起来修库。
说句掏心窝子的：修复数据库的本事，一半靠技术，一半靠冷静。技术可以慢慢积累，但冷静这种素质，真得靠一次次半夜故障磨出来。我给你的建议是，平时没事儿就在测试环境模拟各种故障场景——删表、断电、杀进程、损坏数据文件，练得多了，真出事的时候你手不抖心不慌。另外，备份永远是你的底牌，每一条备份策略都得验证过能恢复才叫备份，不然就是一堆废文件。把这篇文章收藏起来，下次遇到库出问题，翻出来对着做，至少能让你少走几个弯路。
