“incorrect key file for table”错误仅出现在myisam表，innodb表执行repair table会直接报error 1031；必须先用show create table或show table status确认engine=myisam，再结合check table结果和错误日志判断损坏程度，按quick→默认→extended顺序修复，并确保磁盘空间充足。
“Incorrect key file for table” 错误只出现在 MyISAM 表上，InnoDB 表不会触发这个报错，执行 REPAIR TABLE 会直接返回 ERROR 1031 (HY000): Table storage engine for the table doesn't support repair。
确认是不是 MyISAM 引擎
别跳步——先验证引擎类型。InnoDB 表出现类似现象（如复制中断、查询失败）往往是日志损坏或事务不一致，跟 .MYI 文件完全无关。
- 运行
SHOW CREATE TABLE table_name;，检查输出里是否含ENGINE=MyISAM - 若看到
ENGINE=InnoDB或其他引擎，立刻停手，不要尝试REPAIR TABLE - 也可以查
SHOW TABLE STATUS LIKE 'table_name';，看Engine列和Comment列（若标有crashed，基本坐实）
查错误日志定位具体表和时间点
MySQL 错误日志里藏着关键线索，光看报错信息不够，得知道它哪次启动/哪条 SQL 触发的。
- 先查日志路径：
SELECT @@log_error; - 用
grep -i "crashed\|Incorrect key file" /var/lib/mysql/xxx.err找最近几条记录 - 重点关注带表名和 .MYI 后缀的行，例如
Error 'Incorrect key file for table './mydb/tbl.MYI'—— 这个路径说明问题在/var/lib/mysql/mydb/tbl.MYI - 如果日志里反复出现同一张表，且时间集中在断电、
kill -9或磁盘满之后，基本可锁定根因
用 CHECK TABLE 判断损坏程度再决定怎么修
CHECK TABLE 不是摆设，它能告诉你该用什么模式修，乱用 EXTENDED 可能白忙活还占空间。
- 运行
CHECK TABLE table_name;：- 返回
status = OK→ 表当前可用，不用修（可能是临时缓存或并发冲突） - 返回
Msg_text含record delete-link chain broken或data record is corrupted→ 必须修，且得加EXTENDED模式 - 返回
Incorrect key file但没提数据损坏 → 很可能只是 .MYI 索引文件断裂，QUICK模式就够
- 返回
- 别跳过这步直接
REPAIR TABLE：轻度损坏用QUICK几秒完成；重度损坏硬上QUICK会报错并提示 “use EXTENDED”
磁盘空间不足是隐藏推手，必须提前清理
很多修复失败不是命令写错，而是磁盘没给够临时空间——REPAIR TABLE ... EXTENDED 会生成临时索引文件，大小接近原 .MYD + .MYI 总和。
- 执行前务必跑
df -h /var/lib/mysql，剩余空间至少 ≥ 对应表.MYD文件大小的 2 倍 - 如果磁盘已满，先停掉慢日志：
SET GLOBAL slow_query_log = 'OFF'; - 删 binlog：
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY); - 清空
/tmp或 MySQL 的tmpdir（查SELECT @@tmpdir;），避免#sql-*临时文件卡住
真正麻烦的是那种 .MYI 文件为空或时间戳早于故障发生时间的情况——这意味着 mysqld 启动时连索引头都读不出来，必须停服务后用 myisamchk 离线修复，而且得先备份三件套（.FRM、.MYD、.MYI），否则一个操作失误就真丢数据。
