MySQL数据库表损坏这事儿，干过几年运维的人基本都碰上过。前阵子一个朋友半夜打电话，说公司在线商城突然报错，查了半天发现是订单表坏了，数据读不出来。这种情况其实挺常见的，可能是服务器突然断电，也可能是硬盘坏道，甚至有时候就是个bug。表损坏后，最怕的是慌神，上来就瞎折腾，反而把数据弄丢了。所以我今天想跟你聊聊，怎么一步步把损坏的表救回来。
第一步是确认问题。别急着跑修复命令，先看看MySQL的错误日志。一般在/var/log/mysql/error.log里，或者你可以在MySQL命令行里用SHOW ENGINE INNODB STATUS;查看最近的状态。如果看到一个表查询时报“Table is marked as crashed and should be repaired”，或者“Incorrect key file for table”，基本可以确定是表结构或索引出了问题。这时候别慌，先备份整个数据库文件夹，特别是那个表对应的.frm和.ibd文件。备份是底线，修复过程万一出岔子，至少还能回滚。
确认坏表后，最稳妥的办法是用MySQL自带的修复工具。对于MyISAM引擎的表，你可以用REPAIR TABLE命令，比如：REPAIR TABLE orders;。这个命令会尝试重建索引和修复数据文件。如果不行，再加个选项：REPAIR TABLE orders USEFRM;，这个会尝试用.frm文件重建表结构。但说实话，MyISAM引擎现在用得少了，大部分系统都转成了InnoDB。InnoDB的修复要复杂一些，因为它的数据文件是共享的，不能像MyISAM那样单独拎出来修。InnoDB的常见做法是先设置innodbforcerecovery参数，从1到6逐步递增，每次重启MySQL看看能不能读表。比如设置成1，跳过坏页检查；设置成4，跳过回滚操作。每调一次，就尝试用SELECT FROM orders LIMIT 1;看能不能读出数据。如果读到数据，赶紧用mysqldump导出，然后重建表。
如果innodbforcerecovery开到6还是不行，那就得动用mysqlcheck这个命令行工具了。用法是：mysqlcheck -r 数据库名 表名。这个命令会尝试多种修复策略，包括重建索引、修复数据页。注意，-r参数是repair，-o是optimize，别搞混了。我见过有人用mysqlcheck -o去修坏表，结果越修越乱。还有个小技巧：如果单表修复不成功，可以试试mysqlcheck -r --databases 数据库名，让工具一次性修复整个库里的所有表。但前提是数据库不大，不然执行时间会很长。
有些情况下，MySQL自带的工具搞不定，就得用第三方工具了。比如Percona Toolkit里的pt-table-checksum和pt-table-sync，但这两个主要是检查主从数据一致性的，不适合直接修坏表。真正能修的是Twindb的InnoDB Recovery Tool，它可以直接解析.ibd文件，尝试恢复损坏的数据页。不过这个工具收费，而且需要点Linux系统编程基础。更实际的做法是用命令从.ibd文件里提取文本数据：strings orders.ibd > orders.txt。虽然会丢掉二进制字段和格式，但至少能把订单描述、用户名这些文本信息捞出来。我帮人恢复过几次，用这个方法捞回了90%的数据。
修复过程中有几个坑必须避开。第一，别在修复期间直接修改表结构，比如加字段、改索引，这会让损坏更严重。第二，别用去重建表，这个命令在坏表上执行可能会卡死整个数据库。第三，如果数据很重要，优先用mysqldump导出，哪怕只导出一部分记录，也比硬修强。比如：mysqldump -u root -p --force --quick databasename tablename > backup.sql。--force参数会忽略错误继续导出，--quick则避免把整个表加载到内存里。导出成功后，删掉坏表，用导出的SQL重建。
修复完成后，一定要做三件事。第一，跑一遍，确认表状态变成OK。第二，更新表的统计信息：ANALYZE TABLE orders;，让查询优化器正常工作。第三，重新建立外键和索引，因为修复过程中有些索引可能被重建得不完整。外键检查可以用，对比修复前的备份。如果发现缺失，手动加回去。别偷懒，这一步省了，后面查询慢起来你更头疼。
说句实在话，修复表只是救急，预防才是根本。日常运维里，做好备份是王道。我建议每天用mysqldump做一次逻辑备份，再用xtrabackup做一次物理备份。另外，定期用优化所有表，能减少碎片积累。如果条件允许，给MySQL配个高可用架构，比如主从复制或Galera集群，单节点坏了也不影响业务。表损坏就像人生病，预防比治疗重要得多。
