必须先确认引擎为MyISAM，否则REPAIR TABLE无效甚至有害；InnoDB出现该提示属误判，应查错误日志中InnoDB: Starting crash recovery；磁盘空间不足时需先清理再修复，修复后须CHECK TABLE验证并ANALYZE TABLE更新统计信息。
看到 Table is marked as crashed 就跑 REPAIR TABLE，八成修不对——这个错误只对 MyISAM 表有效，InnoDB 根本不会被标记为 crashed；误判引擎类型硬修，轻则失败，重则让表彻底不可读。
先确认是不是 MyISAM 表，否则别动
MySQL 不会主动告诉你报错表是什么引擎，必须查。InnoDB 出现该提示，基本是日志误读、备份残留或应用层复用了旧错误逻辑。
- 执行
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';，返回MyISAM才继续 - 或者用
SHOW CREATE TABLE your_table;看ENGINE=后面的值 - 如果返回
InnoDB或NULL（说明表不存在），立刻停手，转去看错误日志里有没有InnoDB: Starting crash recovery
磁盘空间不足时，修表大概率失败
90% 的 MyISAM 表损坏源于写入中断，而磁盘满是最常见诱因。REPAIR TABLE EXTENDED 需要临时空间 ≥ .MYD + .MYI 文件总和，剩几百 MB 时硬跑，会卡住并留下 #sql-*.MYD 这类半截临时文件，后续更难清理。
- 先运行
df -h，重点看 MySQLdatadir所在挂载点（如/var/lib/mysql或/www/server/data） - 若使用率 ≥95%，先停慢日志：
SET GLOBAL slow_query_log = 'OFF'; - 清理 binlog：
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);（确认从库已同步） - 删掉
datadir下以#sql-开头或ibtmp1这类明显异常的大文件
REPAIR TABLE 参数怎么选才不翻车
REPAIR TABLE 不是万能按钮，不同损坏程度得配不同模式，乱用可能放大问题。
- 仅索引损坏（
SHOW TABLE STATUS中Comment显示crashed，但还能SELECT出数据）：用REPAIR TABLE your_table QUICK;，快且安全 - 索引严重错乱或
.MYI文件异常（myisamchk -s报key file is old）：用REPAIR TABLE your_table EXTENDED;，耗时长、占空间多 -
.MYI完全丢失或myisamchk -s报key file is old且EXTENDED失败：只能上REPAIR TABLE your_table USE_FRM;，风险高，修完必须立刻ANALYZE TABLE your_table;，否则查询走全表扫描
修复后必须验证，不能只看“OK”
REPAIR TABLE 返回 status: OK 只代表命令执行成功，不代表数据完整。尤其 USE_FRM 模式下，MySQL 是靠 .frm 文件硬推索引结构，如果 .MYD 本身也损坏，部分行记录可能永久丢失。
- 修复后立刻执行
CHECK TABLE your_table;，确认返回Status: OK - 抽样查关键业务字段，比如时间戳是否连续、主键是否跳号、金额类字段有无异常零值
- 对比修复前后
SELECT COUNT(*)结果，若有明显差异，说明底层数据已损，得从备份恢复
真正棘手的是 .frm 文件损坏或跨版本不兼容——它无法用 SQL 修复，myisamchk 也无能为力，只能靠备份里的 .frm 替换。而这种损坏往往不报错，只在启动或首次访问时触发 ERROR 1033 (HY000): Incorrect information in file，容易被忽略。
