表损坏的修复：check table 与 myisamchk

表坏了还能修吗？多数情况能，但动手顺序很关键：先备份，再修复。抱着"修一下试试"的心态直接对生产表动手，一旦修坏，连原来的坏数据都保不住。 怎么判断是表损坏 典型症状：查询某张表报 Table xxx is marked as crashed、查询中途卡死、重启后表打不开。先做确认： CHECK TABLE applog; 返回 status 为 OK 就没事；出现 error 或 crashed 才进入修复流程。查询慢但能查的，先看执行计划，别急着往损坏上猜——表损坏通常伴随明确的报错，不会只是慢。 MyISAM 表怎么修 MyISAM 是 MySQL 早期的表引擎，不支持事务，损坏概率相对高。两种修法： SQL 层：REPAIR TABLE applog; 文件层（需要停库或确认表无写入）：myisamchk -r /var/lib/mysql/appdb/applog.MYI -r 是常规修复；损坏严重换 -o，再不行用安全模式，但要有丢失部分数据的心理准备。修复前务必先把表文件 cp 一份出来。两层修法效果一致：能停库就用文件层，不能停就走 SQL 层，别两把一起上。 InnoDB 页损坏怎么办 InnoDB 严格说不是"表损坏"，而是页损坏——数据按 16K 的页组织，某一页校验出错，REPAIR TABLE 对它无效。正确思路是从最近备份把该表恢复成新表，再补齐增量数据。出错时错误日志会写明页号和校验值，把日志段留好，恢复和事后归因都用得到。innodb_force_recovery 参数能在极端情况下抢救数据导出，但它会让部分功能降级，只能当抢救手段，不能当日常方案；级别从 1 往上试，超过 4 可能造成不可逆后果，动手前先把物理文件备份一份。 怎么预防 定期全量加增量备份是最根本的防线；关库用 mysqladmin shutdown 正常关闭，别直接 kill -9；磁盘用 RAID 或多副本云盘，坏道是页损坏的常见来源。表损坏是低频事件，备份到位，它就只是一次恢复作业而不是灾难。恢复流程写到命令级别并定期演练，值班同事照着文档就能独立完成。