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