先确认表引擎是否为myisam，该错误仅对myisam有效；innodb出现此提示属误判，需查备份残留或日志误读，确认后方可使用repair table或myisamchk修复。
先确认是不是MyISAM表，否则别修
看到 Table is marked as crashed 就去跑 REPAIR TABLE，大概率白忙活——这个提示只对 MyISAM 表有意义。InnoDB 表根本不会被标记为 crashed，出现该报错，基本是备份残留、日志误读或应用层错误复用了 MyISAM 的错误逻辑。
查准引擎类型再动手：
-
SHOW TABLE STATUS LIKE 'your_table_name';看Engine列值 - 或执行
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';
如果是 InnoDB，立刻停手，转去看错误日志里有没有 InnoDB: Starting crash recovery...；有，就等它自己恢复；没出现或卡住，才考虑 innodb_force_recovery 配置。
磁盘空间不足？先腾地方再修表
90% 的 MyISAM 表损坏背后是磁盘写入中断，而根源往往是 /var/lib/mysql 所在分区满了。强行修表可能失败，还留下半截 .TMD 临时文件，让后续更难处理。
修之前必须做三件事：
- 用
df -h查分区使用率，重点看mysql数据目录挂载点 - 若满，先停慢日志：
SET GLOBAL slow_query_log = 'OFF'; - 清理 binlog：
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);（确认从库已同步） - 删掉
/var/lib/mysql/下以#sql-开头或ibtmp1这类临时大文件
REPAIR TABLE ... EXTENDED 模式需要临时空间 ≥ .MYD + .MYI 文件总和，磁盘只剩几百 MB 时硬跑，几乎必败。
REPAIR TABLE 怎么选参数才不翻车
REPAIR TABLE 不是万能按钮，不同损坏程度得配不同模式：
- 仅索引损坏（
SHOW TABLE STATUS中Comment显示crashed，但数据还能 SELECT）：用REPAIR TABLE t QUICK;，快且安全 - 索引严重错乱或
.MYI文件异常：用REPAIR TABLE t EXTENDED;，会逐行重建索引，耗时长、占空间多 -
.MYI完全丢失或myisamchk -s报key file is old：只能上REPAIR TABLE t USE_FRM;，风险高，修完必须立刻ANALYZE TABLE t;，否则查询走全表扫描
注意：USE_FRM 不是“重试一次”，它是靠 .frm 和 .MYD 硬推索引结构，.MYD 若也损坏，结果不可控。
myisamchk 离线修复的硬性前提
myisamchk 是直接操作磁盘文件的离线工具，MySQL 进程只要在跑，就可能缓存或锁住 .MYD/.MYI，强行运行极易二次损坏。
执行前必须满足四点：
- 停 MySQL：
systemctl stop mysql（或对应服务名） - 确认数据目录：
mysql -e "SHOW VARIABLES LIKE 'datadir';"，别默认去/var/lib/mysql - 进对数据库子目录：
cd /var/lib/mysql/your_db_name/ - 先备份：
cp table.MYD table.MYD.bak && cp table.MYI table.MYI.bak
常用命令是 myisamchk -r -v table.MYI，-r 表示安全修复，-v 输出过程方便定位卡点；-o（强制修复）只在 -r 失败后谨慎尝试，有丢数据风险。
修完别忘了重启 MySQL，并用 CHECK TABLE 验证结果——修复完成不等于数据完好，有些逻辑损坏要靠业务侧校验才能发现。
