MyISAM表损坏需先确认引擎类型和损坏状态，再按CHECK TABLE结果选择REPAIR TABLE模式；修复前必须备份三文件、检查tmpdir空间与权限；失败后停服用myisamchk --safe-recover --force修复。
MyISAM 表报 “Table is marked as crashed” 或查询直接失败，基本就是 .MYI 索引文件损坏或 .MYD 数据链断裂，必须人工干预——InnoDB 不会出现这个错误，别在 InnoDB 表上浪费时间试 REPAIR TABLE。
怎么确认真是 MyISAM 表且已损坏
跳过这步就动手修，大概率把还能读的数据搞丢。SHOW CREATE TABLE table_name; 必须返回 ENGINE=MyISAM；如果返回 ENGINE=InnoDB，立刻停手。CHECK TABLE table_name; 是唯一可靠判断方式：返回 Status: OK 就不用修；返回 Msg_text 含 record delete-link chain broken、data record is corrupted 或 Incorrect key file，说明已坏，且类型决定了后续用哪种修复模式。
REPAIR TABLE 三种模式的实际效果和风险
默认 REPAIR TABLE table_name; 等价于 QUICK 模式，只重建 .MYI，不碰 .MYD。快，但只对索引节点断裂有效；一旦 CHECK TABLE 提示数据链损坏，它会直接报 Failed repairing the table。真要修数据层，得用 REPAIR TABLE table_name EXTENDED;——它逐行扫描 .MYD 并重建全部文件，但要求 tmpdir 剩余空间 ≥ 表原始大小的 2 倍，且全程全表锁死。最危险的是 USE_FRM：当 .MYI 完全无法解析时才用，它丢弃原索引，按 .FRM 结构重建空索引，UNIQUE 约束失效、全文索引语义丢失都可能发生，修完必须立刻 ANALYZE TABLE。
修复前必须做的三件事，缺一不可
MyISAM 修复无事务、无回滚，出错即不可逆。
备份原始三文件：cp /var/lib/mysql/dbname/table_name.{MYD,MYI,FRM} /backup/，哪怕只是临时目录也比没强。
查磁盘空间：SELECT @@tmpdir;，进该路径用 df -h 确认剩余空间 ≥ .MYD 文件大小的 2 倍（EXTENDED 模式会生成 table_name.TMD 临时文件）。
确认权限：mysql 用户必须对 tmpdir 有读写权，否则报 Errcode: 13 (permission denied)。
修复失败后只能切到 myisamchk，但必须停服务
REPAIR TABLE 返回 Operation failed，说明损坏已深入物理层，SQL 层无能为力。
先停 MySQL：systemctl stop mysql，确保无残留进程。
再运行：myisamchk --safe-recover --force /var/lib/mysql/dbname/table_name.MYI。--safe-recover 会尝试从 .MYD 中提取可读行，比 SQL 层更底层；--force 强制跳过校验错误继续。
若仍报 Key block size is wrong 或大量 Record-length mismatch，基本意味着文件系统级损坏或硬件问题，这时只能从备份恢复，别硬扛。
