MyISAM表索引损坏应优先用REPAIR TABLE，InnoDB则依赖自动崩溃恢复；MyISAM修复需据CHECK TABLE结果选QUICK、EXTENDED或USE_FRM模式，修复后须ANALYZE TABLE并验证查询。
MyISAM 表索引损坏必须用 REPAIR TABLE；InnoDB 表一般不需要手动修复，靠崩溃恢复机制自动处理，强行用 REPAIR TABLE 反而会报错或无效。
MyISAM 表索引损坏时，REPAIR TABLE 怎么用才不翻车
MyISAM 的 .MYI 文件损坏后，最常见错误是：Incorrect key file for table 'xxx'; try to repair it。这时直接执行 REPAIR TABLE 是最快路径，但得看损坏程度选参数：
- 先跑
CHECK TABLE xxx：返回status = OK就不用修；若提示error或warning，再动手 - 默认
REPAIR TABLE xxx是QUICK模式，只重建索引树，不校验数据行——速度快，但对“记录删除链断裂”类问题无效 - 如果
CHECK TABLE提示record delete-link chain broken，必须加EXTENDED：REPAIR TABLE xxx EXTENDED - 严重损坏（比如
.MYI读取失败）会触发USE_FRM模式：丢弃原索引，仅靠.FRM结构重建，期间表锁死、耗时长，且无法保证索引指向的.MYD行号准确
InnoDB 表报索引相关错误，别硬上 REPAIR TABLE
InnoDB 不支持 REPAIR TABLE 命令（执行会报 Table 'xxx' doesn't support repair）。它依赖事务日志（redo log）和双写缓冲（doublewrite buffer）实现崩溃安全，大多数“索引异常”其实是缓存不一致或元数据错位，不是物理损坏：
- 遇到查询卡住、
SELECT返回乱序或UNIQUE KEY冲突，优先跑CHECK TABLE xxx—— InnoDB 下它只检查页校验和和 B+ 树逻辑结构，不修东西 - 真有物理损坏（极少见），MySQL 启动时会自动进入
innodb_force_recovery模式尝试加载，此时应立即导出数据：mysqldump -u root -p --single-transaction db_name table_name > backup.sql - 导出后删表重建，再导入。不要试图用
ALTER TABLE ... ENGINE=InnoDB“重刷”索引——这本质是重建表，但不会跳过损坏页，可能中断
修复后必须验证，否则等于没修
REPAIR TABLE 返回 OK 只代表命令执行成功，不代表索引能正常工作。尤其 MyISAM 的 .MYI 不存数据校验和，修复后可能指向错误的 .MYD 行号：
- 立刻执行
ANALYZE TABLE xxx，更新统计信息，否则优化器仍按旧分布估算，容易走错执行计划 - 对关键查询跑
EXPLAIN，确认key列显示预期索引名，rows值合理（非全表扫描） - 若有
UNIQUE索引，查重复：SELECT key_col, COUNT(*) FROM xxx GROUP BY key_col HAVING COUNT(*) > 1 - 全文索引（
FULLTEXT）和前缀索引（如INDEX (name(10))）在修复中可能被跳过，需单独验证查询行为
别等坏了才修：碎片和崩溃风险要提前控
频繁 REPAIR TABLE 是系统亚健康信号。MyISAM 的根本问题是无事务、无崩溃安全写入，而 InnoDB 的“自愈”能力也依赖配置是否到位：
- MyISAM 表建议加
myisam_recover_options=FORCE,BACKUP到my.cnf，让 MySQL 启动时自动检查并备份损坏表（但不能替代定期CHECK TABLE） - InnoDB 必须确保
innodb_doublewrite=ON（默认开启），禁用它等于主动放弃页损坏防护 - 碎片不是损坏，但长期不处理会让范围查询变慢：
SHOW TABLE STATUS LIKE 'xxx'看Data_free，大于 0 就说明有空洞；用OPTIMIZE TABLE或ALTER TABLE xxx ENGINE=InnoDB重整，但别高频操作
