做数据库运维这些年，最怕半夜接到电话，那头传来一句 “MySQL崩了，表打不开了”。那种感觉，就像你正睡得香，突然有人告诉你房子着火了。前几天一个朋友就碰上这事儿，他的电商库的订单表突然报错，提示 “Table xxx is marked as crashed”，后台直接一片 404。他急得满头大汗，问我怎么办。说实话，MySQL 文件损坏这事儿，说大不大说小不小，但处理不好，数据丢了，老板能让你把键盘吃了。
先说说为什么文件会坏。MySQL 的存储引擎主流有两种，MyISAM 和 InnoDB。MyISAM 这老家伙，写数据时如果服务器突然断电、进程被 kill，或者磁盘空间满了，文件头部的标记位来不及更新，表就会报错。InnoDB 相对皮实些，有 redo log 和 doublewrite buffer 保护，但也不是金刚不坏。比如磁盘坏道、文件系统 bug，或者手贱直接 cp 复制 ibd 文件到另一台机器，都可能把数据搞残。我见过最离谱的一次，是运维同事在磁盘快满时执行了 OPTIMIZE TABLE，结果新文件写到一半，旧文件被删了，直接挂了。
那遇到表损坏了怎么办？别慌，先判断症状。最常见的报错就是 “Table is marked as crashed” 或者 “Got error 134 from storage engine”。这时候第一步，先备份出库目录，别在原始文件上瞎折腾。用 MySQL 自带的检查工具 myisamchk，命令很简单：myisamchk /var/lib/mysql/库名/表名.MYI。它会告诉你文件有没有问题，问题出在索引还是数据。如果只是索引损坏，加个参数直接修：myisamchk -r 表名。这招对大部分 MyISAM 表有效，修复速度也快，几秒到几十秒不等。
但如果 -r 搞不定，或者报错更严重，就得升级到 -f（force）模式。myisamchk -f 会把表的索引全部重建，甚至强行修复数据文件。注意，-f 会尝试恢复丢失的数据，但可能会丢掉部分记录。我有个教训：当年修一个论坛的 posts 表，用 -f 跑完后，发现少了千余条帖子，全是从某一天开始断档的。后来查日志，发现那天磁盘有坏道，数据文件中间缺了一块。所以，修复前一定先备份损坏的文件，哪怕它已经残缺，也比没有强。
InnoDB 的表损坏就麻烦多了。因为 InnoDB 的数据和索引都在同一个 ibd 文件里，而且有事务日志，不能直接用命令行修复。最常见的场景是：重启 MySQL 后，发现某个表打不开，报错 “Tablespace is missing” 或者 “Corrupted page”。这时候第一步，先看错误日志，找到具体是哪一页出问题。然后尝试用 innodbforcerecovery 参数启动 MySQL。这个参数从 1 到 6，数字越大恢复力度越大，但副作用也越强。比如 innodbforcerecovery=1 会跳过损坏页的检查，让你能先导出数据；=4 会跳过 undo log，可能导致事务回滚不完整。我一般从 1 开始试，导完数据就赶紧重建表，别长期带着这个参数跑，否则数据一致性无法保证。
如果 innodbforcerecovery 也搞不定，就要上终极大法：用 mysqlfrm 或者 Percona 的工具提取表结构，然后用脚本把数据一行行读出来。有个开源工具叫 “mysql-udf-http”，配合 SELECT … INTO OUTFILE，可以把损坏表的数据导出成 CSV。前提是你还能连上 MySQL，哪怕只是只读模式。最惨的情况是 ibd 文件彻底坏了，连读都读不了。这时候只能靠备份了。所以，我实话实说，数据库恢复的终极手段不是修复，而是备份。没有备份，你就是在赌命。
说到备份，很多人以为 mysqldump 跑一遍就万事大吉。但 dump 出来的文件，如果在线跑且不加 --single-transaction 参数，MyISAM 表会被锁住，影响业务。InnoDB 表不加 --master-data，恢复时找不到 binlog 位点。更坑的是，有些运维图省事，直接 tar 打包整个 data 目录，结果恢复时发现文件大小对不上，或者字符集不匹配。我建议，生产环境至少做两套备份：一套全量物理备份（比如 Percona XtraBackup），每天一次；一套 binlog 增量备份，每 5 分钟一次。这样即使文件坏了，也能恢复到接近实时的状态。
说个真实案例。去年一个朋友的金融系统，核心库的 ibdata1 文件坏了一个页，导致整个库起不来。他试了 innodbforcerecovery=6 仍无效，急得差点想格式化。后来我用 Percona Data Recovery Tool for InnoDB，直接解析 ibd 文件的二进制内容，把数据一行行捞出来。整个过程花了 8 小时，捞出了 97% 的数据，丢失的 3% 是在损坏页里的。他老板虽然不爽，但看到大部分数据保住了，也就没有追究。这个案例让我明白一件事：数据库文件损坏不可怕，可怕的是没有预案、没有工具、没有备份。平时多花十分钟做备份，关键时刻就能少花十个小时去修数据。
