能用，但仅限myisam引擎；innodb执行会报错error 1031，需通过崩溃恢复而非修复，且修复前须确认引擎、备份文件并检查磁盘空间。
MySQL提示表损坏时，REPAIR TABLE还能用吗
能用，但只对MyISAM引擎有效，InnoDB表执行会直接报错：ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair。别急着敲命令，先确认引擎类型：SHOW CREATE TABLE `table_name`; 或查 information_schema.tables 里的 ENGINE 字段。
常见误操作是看到“table is marked as crashed”就无脑运行 REPAIR TABLE，结果在 InnoDB 上浪费时间还可能触发锁等待。如果是 InnoDB，得走崩溃恢复流程，不是修表而是重启+日志重放。
REPAIR TABLE 的三种模式怎么选
REPAIR TABLE 默认走标准修复（REPAIR），但遇到索引严重错乱或数据页损坏时可能失败。这时要手动指定模式：
-
REPAIR TABLE tbl_name QUICK：只修复索引文件（.MYI），快但不校验数据行，适合索引损坏但数据完好 -
REPAIR TABLE tbl_name EXTENDED：逐行重建索引，比默认更彻底，但耗时长、占磁盘空间多（需要临时空间存重建的索引） -
REPAIR TABLE tbl_name USE_FRM：极端情况用——当.MYI完全丢失或不可读，且你有完好的.frm表结构文件，它会尝试从.frm和.MYD中硬推数据。风险高，可能丢数据，仅作最后手段
修复前必须做的三件事
跳过这些步骤，修表可能让问题更糟：
- 确认 MySQL 没在写入该表：查
SHOW PROCESSLIST;，避免修复中途被 INSERT/UPDATE 干扰 - 备份原始文件：进数据目录（如
/var/lib/mysql/dbname/），把table_name.MYD、table_name.MYI、table_name.frm打包拷走——REPAIR TABLE会直接改原文件，没备份等于裸奔 - 检查磁盘空间：
EXTENDED模式可能需要等同于表大小的临时空间，df -h看清/var/lib/mysql所在分区剩余空间
修复后验证数据是否真正常
命令返回 OK 不代表数据完好。尤其 USE_FRM 模式下，字段顺序错位、NULL 值被填成默认值都可能发生：
- 跑
CHECK TABLE table_name;看是否仍报status: OK - 抽样查关键字段：比如主键连续性（
SELECT id FROM table_name ORDER BY id DESC LIMIT 5;）、业务核心字段非空率（SELECT COUNT(*) FROM table_name WHERE status IS NULL;） - 对比修复前后行数：
SELECT COUNT(*) FROM table_name;—— 如果差几百行以上，说明有记录被跳过或截断
最常被忽略的是字符集和排序规则一致性。如果表用 utf8mb4_unicode_ci，但修复后 SHOW CREATE TABLE 显示成了 utf8mb4_general_ci，后续模糊查询可能出偏差，得手工 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
