必须先确认引擎类型，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 不存数据校验和，这种错位只能靠业务查询结果反推，没法自动发现。
