MySQL中MyISAM的.MYI索引文件损坏后如何快速修复

必须先确认引擎类型，REPAIR TABLE仅适用于MyISAM表，InnoDB执行会报ERROR 1031；系统库表如mysql.user在5.7及以前默认MyISAM，8.0+已转InnoDB，需用SHOW CREATE TABLE或information_schema查实引擎。

先确认是不是MyISAM引擎，别修错表

看到 Incorrect key file for table 'xxx' 或 Table is marked as crashed 就动手？先停一秒。InnoDB 表根本不能用 REPAIR TABLE，强行执行会报 ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair。必须先验证引擎：

• SHOW CREATE TABLE xxx; 看输出里有没有 ENGINE=MyISAM
• 或者查元数据：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'xxx';

系统库（如 mysql.user）在 MySQL 5.7 及更早版本默认是 MyISAM，但 8.0+ 已转 InnoDB——别被旧经验带偏。

CHECK TABLE 结果决定用哪种 REPAIR 模式

CHECK TABLE xxx 不是摆设，它返回的 Msg_text 直接告诉你该怎么修：

• 返回 status = OK：不用修，可能是缓存或临时状态异常
• 提示 record delete-link chain broken：数据链断裂，REPAIR TABLE xxx EXTENDED 是唯一靠谱选择
• 报 key file is corrupted 但没提数据问题：先试 REPAIR TABLE xxx（等价于 QUICK），快且安全
• 连 .MYI 都读不出来（比如 Can't read keyfile）：只能上 REPAIR TABLE xxx USE_FRM，但修复后索引指向可能错位，必须后续验证

USE_FRM 模式会锁死表、耗时长，且不校验数据一致性——只在 .MYI 文件丢失或彻底损坏时才考虑。

修复前必须检查三件事，缺一不可

MyISAM 修复不可逆，失败可能让表彻底不可读：

• 磁盘空间：REPAIR TABLE EXTENDED 会生成临时文件（xxx.TMD），空闲空间至少得 ≥ 原 .MYI 文件大小的 2 倍。查路径：SELECT @@tmpdir;
• 权限：数据库目录下 xxx.MYD、xxx.MYI、xxx.frm 三个文件属主必须是 mysql 用户，否则修复中途会静默失败
• 备份：哪怕只是 cp xxx.{MYD,MYI,frm} /backup/，也比没备份强。修复过程不支持回滚

特别注意：.frm 是二进制文件，被 vim/cat 修改过、或跨 MySQL 版本拷贝（比如 5.7 的 .frm 放到 8.0 实例），会导致 ERROR 1033 (HY000): Incorrect information in file，这时 REPAIR TABLE 根本不会启动。

修复后不验证 = 白修

REPAIR TABLE 返回 OK 只代表命令跑完，不代表索引能用：

• 立刻执行 ANALYZE TABLE xxx：MyISAM 的统计信息不会自动更新，优化器还按旧分布估算，容易走全表扫描
• 对关键查询跑 EXPLAIN SELECT ...：确认 key 列显示预期索引名，rows 值明显下降（比如从 100 万降到几百）
• 有 UNIQUE 索引？必须查重复：SELECT key_col, COUNT(*) FROM xxx GROUP BY key_col HAVING COUNT(*) > 1 —— REPAIR TABLE 可能跳过冲突行而不报错

最隐蔽的问题是索引指向了错误的 .MYD 行号：MyISAM 的 .MYI 不存数据校验和，这种错位只能靠业务查询结果反推，没法自动发现。