上周四晚上十一点，我正窝在沙发上刷手机，突然手机震个不停——客户发来一连串语音，语气里带着哭腔：“网站打不开了，所有订单页面都报错，数据库好像崩了。”我赶紧打开电脑，远程连上服务器，一查，心里凉了半截：MySQL 服务挂掉了，重启后报错显示“表损坏”，InnoDB 引擎的 ibdata 文件疑似出了问题。这种场景运维的朋友都懂——心跳加速、手心冒汗，脑子里瞬间闪过好几个念头：数据能救回来吗？备份是多久之前的？客户要是知道数据丢了会不会直接翻脸？
这种慌乱感其实很真实。MySQL 数据库出故障，就像家里的水管突然爆了，水漫金山时你想的不是翻装修图纸，而是怎么堵住。但干这行久了，我慢慢悟出一个道理：修复数据库最怕的不是技术难题，而是心态崩了。我见过太多同行一发现问题就手忙脚乱，上来就执行 REPAIR 命令，结果把原本还能抢救的数据彻底搞死。正确的姿势应该是先深呼吸，然后按优先级来：第一，立刻停掉所有写入操作，防止数据进一步损坏；第二，检查备份文件是否存在、是否可用；第三，根据错误日志判断是引擎崩溃、表损坏还是硬件故障。这三个步骤走完，你就已经赢了一半。
说到硬件故障，这比软件问题更棘手。去年有个客户，数据库跑在云服务器上，某天早上突然连不上，后台一看磁盘空间满了，I/O 等待时间飙到 90% 以上。这种时候急也没用——硬件层面的问题，软件修复手段基本不起作用。正确的做法是先迁移数据到新磁盘，或者清理不必要的日志文件腾出空间。我见过最离谱的案例，是有人直接把损坏的数据库目录拷贝到另一台服务器上，结果因为文件系统不一致，数据直接变乱码。所以遇到硬件故障，我的经验是：别折腾，先换环境。把数据文件复制到健康服务器上，再用 mysqlcheck 或 mysqldump 尝试导出，成功率比在原机硬扛高得多。
软件层面的损坏，常见的有两种：MyISAM 引擎的表损坏和 InnoDB 引擎的崩溃。MyISAM 的问题相对好解决，因为它采用表级锁定，结构简单。只需要登录 MySQL 命令行，执行 REPAIR TABLE 表名 即可。但这里有个坑——如果表很大，比如几千万行，这个命令可能会跑上好几个小时，期间表被锁定，所有读写都会被阻塞。生产环境千万别在高峰期干这事，我一般会先做个 mysqldump 备份，再在从库或测试环境上修复。InnoDB 的修复就复杂得多，因为它的数据文件是共享的，崩溃后整个实例可能起不来。这时要把 innodbforcerecovery 参数从 1 逐步调高到 6，每次尝试启动，直到能进入只读模式导出数据。这招我用过不少次，最高调到 4 就成功了，调到 6 虽然能启动，但数据可能已经面目全非。
讲个具体案例吧。去年帮一个电商客户修复数据库，他们的订单表有 1200 万条记录，InnoDB 引擎突然崩溃，错误日志显示 “corrupted page”。我按照标准流程，先把 innodbforcerecovery 设为 1，启动失败；设为 2，仍然失败；设为 3，终于启动了，但进到数据库里一看，好几张表显示 “Table doesn't exist”。这时候千万别慌——这些表其实还在，只是元数据损坏了。我用了两个工具：一个是 mysqlfrm，能从 .frm 文件中提取表结构；另一个是 percona‑data‑recovery‑tool，专门扫描 ibdata 文件恢复数据行。折腾了整整一个通宵，最终恢复了 98% 的数据，丢失的 2% 是损坏最严重的页，实在救不回来。客户虽然有点心疼，但看到大部分订单数据都在，还是松了一口气。
备份这事儿，我每次写数据库修复的文章都会提，但真正重视的人不多。很多人觉得“一天备份一次就够了”，结果数据库在凌晨三点崩溃，你恢复出来的数据是昨天中午的，十五个小时的订单全没了。更惨的是，有些备份文件本身就是坏的——备份脚本没做校验，文件写到一半磁盘满了，生成的不完整 SQL 文件根本无法恢复。我见过一个真实案例：某公司数据库 2 TB，每天用 mysqldump 全量备份，某天数据库崩了，他们自信满满地去恢复，结果备份文件只有 800 MB，检查后发现备份过程中网络中断，脚本也没报错。所以我的建议是：备份必须做三重验证——文件大小校验、恢复测试、定时抽查。另外，一定要保留至少最近三天的不同时间点备份，这样遇到损坏时可以回滚到最近的健康点。
说到底，数据库修复是一门“止损”的艺术，而不是“起死回生”的魔法。你得接受一个现实：有些损坏是不可逆的，强行修复只会导致二次伤害。我见过最极端的例子，有人为了修复一张损坏的表，反复执行 REPAIR TABLE 和 OPTIMIZE TABLE，结果把整个数据目录搞崩，只能用文件恢复工具去扫描磁盘碎片。所以我的原则是：能导出数据就导出，导不出来就用备份恢复，备份也没有的话，找专业的数据恢复公司，别自己瞎折腾。毕竟，数据丢了可以再录入，但客户的信任一旦丢了，花多少钱都买不回来。说句实在话：如果今天你还没给数据库做过备份，放下这篇推文，先去设置一个自动备份计划——等你真遇到问题的时候，你会感谢自己的决定。
