必须先确认表引擎为myisam，再选择对应修复方式：repair table（quick/extended/use_frm）或myisamchk离线修复，并严格校验权限与文件完整性。
别急着修，先确认是不是 MyISAM 表——90% 的误操作都卡在这一步。 这个错误只对 MyISAM 有意义，InnoDB 表根本不会被标记为 crashed；如果引擎是 InnoDB 却报这个错，基本是旧备份残留的 .MYI 文件、日志误读，或应用层硬塞了错误提示。
怎么确认表真是 MyISAM 而不是误报
SHOW TABLE STATUS LIKE 'your_table'; 查 Engine 列，必须是 MyISAM；更稳妥的是执行：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';。如果返回 InnoDB，立刻停手，别碰 REPAIR TABLE 或 myisamchk。再补查一遍磁盘文件：ls -l /var/lib/mysql/dbname/table_name.{MYD,MYI,FRM}，三者缺一不可——少一个就不是标准 MyISAM 损坏，而是文件丢失或权限问题。
REPAIR TABLE 命令该用哪个模式
REPAIR TABLE 是在线修复首选，但模式选错等于白干：
-
REPAIR TABLE your_table;等价于QUICK，只重建.MYI索引文件，不碰.MYD数据。适合Incorrect key file类错误，快但失败率高；若报Failed repairing the table，说明数据页也坏了 -
REPAIR TABLE your_table EXTENDED;逐行读取.MYD并重建全部索引，能修多数逻辑损坏，但要求磁盘剩余空间 ≥ 表大小的 2 倍，且全程锁表 -
REPAIR TABLE your_table USE_FRM;仅当.MYI完全丢失或myisamchk -s报Key file is missing时才用。它丢弃原索引，按.FRM结构硬推空索引，修完必须立刻执行ANALYZE TABLE your_table;，否则查询走全表扫描
myisamchk 离线修复必须停服务且修正权限
myisamchk 直接操作磁盘文件，MySQL 进程只要在跑，就可能缓存或锁住 .MYD/.MYI，强行运行极易二次损坏：
- 先停服务：
sudo systemctl stop mysql，再用ps aux | grep mysqld确认无残留进程 - 进对目录：
mysql -e "SHOW VARIABLES LIKE 'datadir';"查准路径，cd /var/lib/mysql/your_dbname - 常用命令：
myisamchk -o your_table.MYI（保守修复，跳过坏块）→ 失败再试myisamchk -r -v your_table.MYI（强力修复，-v看卡点） - 修复后文件属主默认是执行用户（如
root），而 MySQL 以mysql用户运行，必须立刻修正：sudo chown mysql:mysql your_table.*，否则重启后仍报 “crashed” 或 “Can't find file”
真正麻烦的不是修表本身，而是修完发现数据错乱、索引失效、或权限没改导致 MySQL 启动后仍无法读取——这些细节不盯紧，修十次也白搭。
