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

先说几个核心判断：修复MyISAM表之前，必须先确认引擎类型，否则可能修错表。InnoDB表千万别用REPAIR TABLE，否则会报ERROR 1031。系统库表（比如mysql.user）在MySQL 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不存数据校验和，这种错位只能靠业务查询结果反推，没法自动发现。