## 症状现象
数据库表突然报错：查询返回表损坏的提示，mysqldump 导出中断，错误日志里出现页校验失败或表标记为损坏的字样。诱因常见几类：服务器断电或异常关机、磁盘坏块、MySQL 进程被强杀时的写入中断、文件系统故障。损坏发生后第一原则立刻生效：先备份现状，再动手修复，修复操作本身也可能加剧损坏，没有备份的修复是赌博。错误日志是判断损坏类型的第一证据，动手前完整留存，修复过程中的日志同样重要。
## MyISAM 表的修复
MyISAM 是老引擎，修复工具链成熟。停库后用 myisamchk 离线修复：
bash myisamchk -r /var/lib/mysql/mydb/mytable.MYI
-r 是恢复模式，重建索引；损坏更重时用 -o 安全模式，慢但保守；先跑 myisamchk 不带参数只检查，看清损坏程度再选模式。在线方式是 REPAIR TABLE 语句，轻微损坏通常一条命令解决。注意 myisamchk 必须在表无访问时执行，否则越修越坏。
## InnoDB 表的处理
InnoDB 没有对应的外部修复工具，官方路径是借助强制恢复模式把数据导出来重建。在 my.cnf 设置：
innodb_force_recovery = 1
参数从 1 到 6 逐级升高，1 最温和只允许读，6 最激进跳过大量一致性检查。正确姿势是从小值开始：启动实例，立即 mysqldump 导出全部数据，停库，去掉参数，重建库目录后重新导入。数值只升到能启动能导出为止，绝不用高级别长期跑业务，那等于带伤运行。整个操作在恢复演练机上先走一遍更稳。强恢模式下实例是带病运行，导出时机越早越好，久拖不决风险逐日增加。
## 预防建议
事前防护远比事后修复划算：开启 InnoDB 的正常持久化配置，避免强行 kill 与频繁硬重启；重要库保持主从或定时备份，损坏时直接切备份是止损最快的路；顺云控制台的磁盘监控与告警提前暴露坏块苗头。表损坏事件后复盘根因：断电为什么发生、UPS 与集群策略是否缺位、监控为什么没预警。修复工具是急救包，健康度管理才是日常。硬件层面留意磁盘告警，软件层面避免在写入高峰强杀进程，两道防线都到位，表损坏只是小概率事件。