MyISAM表损坏典型现象是报“Table is marked as crashed”或“Incorrect key file”，主因包括异常断电、kill -9终止mysqld、磁盘满或硬件故障；判断依据为错误日志含crashed字样、SHOW TABLE STATUS中Comment列标有crashed，或myisamchk -s检查异常。
MyISAM表损坏的典型现象和判断依据
遇到 Table is marked as crashed 或 Incorrect key file 错误，基本可以确认 MyISAM 表已损坏。这类问题常出现在异常断电、强制 kill mysqld 进程、磁盘空间满或硬件故障后。InnoDB 表通常靠崩溃恢复自动修复，但 MyISAM 没有事务日志，必须人工干预。
先用 myisamchk -s /var/lib/mysql/dbname/table_name.MYI 快速检查（需停库或锁表），或在 MySQL 内执行：
SHOW TABLE STATUS LIKE 'table_name';观察
Comment 列是否含 crashed 字样。
REPAIR TABLE 命令的三种模式怎么选
REPAIR TABLE 默认走快速修复（QUICK），只重建索引文件，不碰数据文件。适合索引损坏但数据完好时——快，但失败率高。若报错 Failed repairing the table，说明数据页也坏了，得换模式。
-
REPAIR TABLE table_name;：默认等价于QUICK，适合轻度损坏 -
REPAIR TABLE table_name EXTENDED;：逐行读取数据并重建整个 .MYD + .MYI，能修复多数损坏，但慢、占 I/O、要求足够磁盘空间 -
REPAIR TABLE table_name USE_FRM;：仅当 .MYI 丢失或完全无法解析时才用——它忽略原索引，按 .FRM 文件结构重新生成空索引，数据还在，但所有索引失效，后续必须ANALYZE TABLE或手动重建
执行前必须做的三件事
别急着敲命令。MyISAM 修复过程不支持事务回滚，出错可能让表彻底不可读。
- 确认表引擎确实是 MyISAM：
SHOW CREATE TABLE table_name;中包含ENGINE=MyISAM - 备份原始文件：复制
/var/lib/mysql/dbname/table_name.MYD、.MYI、.FRM三文件到安全路径（哪怕只是cp *.MYI *.MYD *.FRM /backup/） - 确保磁盘剩余空间 ≥ 表数据大小的 2 倍——
EXTENDED模式会生成临时文件，空间不足直接中断且可能残留损坏碎片
修复失败后还能做什么
如果 REPAIR TABLE ... EXTENDED 仍返回 Operation failed，说明数据块严重损坏或文件系统级错误。这时得切到命令行工具：
停掉 MySQL：systemctl stop mysql，然后用 myisamchk --safe-recover --force /var/lib/mysql/dbname/table_name.MYI。注意：--safe-recover 会尝试从数据文件中提取可读行，比 SQL 层的 REPAIR 更底层；--force 强制继续即使遇到校验错误。
若连 myisamchk 都报 Key block size is wrong 或大量 Record-length mismatch，基本意味着部分数据永久丢失——只能从最近备份恢复，或用 myisamchk --recover --backup 导出还能读的记录，再手工清洗导入。
真正麻烦的不是命令怎么写，而是损坏发生时没人知道——建议对关键 MyISAM 表定期跑 mysqlcheck --check --all-databases，并监控 mysqld 错误日志里的 Got error 关键字。
