必须先确认引擎类型：InnoDB表不会报“Table is marked as crashed”，该错误仅属MyISAM；执行SHOW TABLE STATUS或查information_schema.TABLES确认Engine为MyISAM后，方可使用REPAIR TABLE修复。
别急着跑 REPAIR TABLE —— 先确认是不是 MyISAM 表，否则修了也白修。
怎么一眼看出表引擎是不是 MyISAM
看到 Table is marked as crashed 就动手修，90% 是在给 InnoDB 表做无用功。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'; - 返回
MyISAM才继续；如果是InnoDB，立刻停手，转去看错误日志里有没有InnoDB: Starting crash recovery
磁盘空间不足时硬修 MyISAM 表会失败
MyISAM 表损坏的主因是写入中断，而磁盘满是最常见诱因。REPAIR TABLE ... EXTENDED 需要临时空间 ≥ .MYD + .MYI 文件总和，剩几百 MB 时基本必败，还会留下 #sql-xxx.TMD 半截文件，让后续更难处理。
- 先运行
df -h，重点看/var/lib/mysql所在挂载点使用率 - 若接近 100%，先关慢日志：
SET GLOBAL slow_query_log = 'OFF'; - 清理 binlog：
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);（确认从库已同步） - 删掉
/var/lib/mysql/下以#sql-开头或ibtmp1这类临时大文件
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;，否则查询走全表扫描
用 myisamchk 离线修复前必须停 MySQL
myisamchk 直接操作磁盘文件，MySQL 进程只要在跑，就可能缓存或锁住 .MYD/.MYI，强行运行极易二次损坏。
- 必须先停服务：
systemctl stop mysql（或对应服务名） - 确认 MySQL 已完全退出：
ps aux | grep mysqld应无残留进程 - 检查数据库目录下三个文件是否齐全：
table_name.frm、table_name.MYD、table_name.MYI - 若文件存在但属主不是
mysql用户（如手动拷贝后），执行：chown mysql:mysql *.MYI *.MYD *.frm
真正麻烦的不是修表本身，而是修完发现 .frm 文件损坏或跨版本不兼容——它没法用文本编辑器看，也没法“修”，只能靠备份恢复。一旦 CHECK TABLE 返回 ERROR 1033 (HY000): Incorrect information in file，基本就该翻备份了。
