那天半夜两点，我正睡得迷迷糊糊，手机突然炸响。接起来，运维的小王声音都变了：“哥，数据库崩了，用户登录全挂了！”我一下子清醒过来，光着脚冲到电脑前。登录服务器一看，MySQL报了个 “Table is marked as crashed” 的错误。这种场景，干过几年技术的人都不陌生——数据库损坏就像电脑突然死机一样，来得毫无征兆，却能把人逼疯。
说实话，MySQL 数据库损坏这事儿，真不是稀罕事。我入行那会儿，就听前辈说过一句话：没遇到过数据库损坏的 DBA 不是完整的 DBA。这话糙理不糙。你想想，数据库每天要处理多少读写操作？突然断电、硬盘坏道、服务器死机、甚至一个简单的 bug，都可能导致数据文件出问题。我见过最离谱的一次，是运维小哥半夜升级系统，没注意磁盘空间快满了，结果写日志时把数据文件撑坏了。那哥们儿后来被老板骂了整整一周，但说实话，这种低级错误谁没犯过呢？
最让人头疼的是，MySQL 的损坏表现五花八门。有时候还能正常查询，但一插入数据就报错；有时候表能打开，但统计数据完全对不上；最惨的是直接启动不了服务，或者启动后连表都看不见。我处理过一台生产服务器，用户表损坏到连 都卡死，那感觉就像家大门锁坏了，钥匙插不进去，连门都推不开。更麻烦的是，很多新手碰到这种情况第一反应就是重启——结果重启后问题更严重，原本还能抢救的数据彻底玩完。
那到底怎么判断损失程度呢？有个土办法我用了十年：先看错误日志。MySQL 的日志文件里，通常会明确告诉你哪个表出了问题，是索引损坏还是数据行损坏。比如常见的错误码 1034 表示索引文件损坏，1030 则是数据文件有误。如果日志里只报一两个表，基本问题不大；要是整个数据库目录都报错，那大概率是文件系统或硬件出了问题。我有个习惯，碰到损坏先做三步：备份日志、停止写操作、检查磁盘状态。这三步走完，心里就有底了。
修复方法其实就那几招，但选对路子很重要。最常用的是 MySQL 自带的 和 命令。这俩命令就像数据库的“体检仪”和“急救包”，能自动修复大部分索引损坏。具体操作很简单：先 看看问题在哪儿，然后 让它自己修复。我修过最复杂的一个表，跑 整整三个小时，中间盯着屏幕不敢动，生怕一按键盘就卡死。但要注意，这个方法只适用于 MyISAM 引擎，InnoDB 的修复思路完全不同。
说到 InnoDB，这就有点技术含量了。InnoDB 的损坏通常不是表文件本身，而是日志文件或系统表空间出了问题。我遇到过一台服务器，InnoDB 启动时报 “corrupted in the tablespace”，当时第一反应是完蛋了。后来查资料发现，可以把 参数从 1 调到 6，这相当于给数据库打了强心针，能绕过损坏的数据块启动。但有个坑：参数值越高，数据丢失的风险越大。我一般从 1 开始试，调到能启动服务为止。启动后用 导出数据，再重建数据库，虽然笨，却最稳妥。
如果 MySQL 自带的工具搞不定，那就得上第三方神器。Percona Toolkit 里有 和 ，专门用来检测和修复数据一致性。我用过几次，效果不错。但要注意，这工具对服务器压力不小，别在业务高峰期跑。还有个小技巧：有时候表文件没坏，但索引文件坏了，可以直接删除索引文件再重建，前提是你有备份。说到备份，我见过太多人吃了没备份的亏。有个创业公司的 CTO，数据库坏了才发现备份策略形同虚设——备份文件天天生成，却从未验证过，真要用时发现备份也是坏的。那场面，比电影还精彩。
最极端的情况，就是啥招都试过了，数据还是救不回来。这时就需要用二进制日志（binlog）做时间点恢复。binlog 记录了所有数据变更操作，相当于数据库的“黑匣子”。只要有完整的 binlog，哪怕数据文件全毁，也能恢复到损坏前的任意时间点。我帮朋友恢复过一次：他的数据库在下午三点崩了，但 binlog 只保留到中午十二点。我硬是用中午的备份加上三个小时的 binlog，一条一条回放，终于把数据恢复到下午两点五十九分。那哥们儿后来请我吃了三顿饭，说救了他公司的命。
说到底，数据库损坏修复这事儿，七分靠技术，三分靠运气。但运气这东西，从来都是给有准备的人。我见过太多人平时不备份、不监控、不测试，一出问题就手忙脚乱。真正靠谱的做法，是建立一套完整的防护体系：定期备份并验证、配置监控告警、测试恢复流程。说白了，数据库坏了不可怕，可怕的是你从来没想过它会坏。下次再半夜接到这种电话，别慌，先按步骤来。
