怎么快速修复MySQL MyISAM索引文件损坏

先说几个核心判断：修复 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 不存储数据校验和，这种错位只能通过业务查询结果反向推断，无法自动发现。