repair table 报错“不支持修复”说明表引擎为innodb，该命令仅适用于myisam；需先用show create table确认引擎，innodb损坏应通过innodb_force_recovery导出重建，而非强行修复。
repair table 报错 “The storage engine for the table doesn’t support repair” 怎么办
MySQL 的 REPAIR TABLE 命令只对 MyISAM 表有效，InnoDB 表压根不支持——这是最常卡住人的第一关。如果你执行 REPAIR TABLE user_logs; 得到这个错误，说明表引擎是 InnoDB，硬修没用。
- 检查引擎：运行
SHOW CREATE TABLE user_logs;，看输出里ENGINE=InnoDB还是ENGINE=MyISAM - MyISAM 才能修：只有
ENGINE=MyISAM时，REPAIR TABLE才真正起作用 - InnoDB 表损坏不能靠它：强行执行只会报错，还可能掩盖真实问题（比如磁盘故障或崩溃未刷盘）
修复 InnoDB 表得走另一条路：先确认数据是否还能读，再考虑 innodb_force_recovery 启动参数导出、重建。
check table 显示 “error: record is crashed” 但表还能查，要不要立刻修
CHECK TABLE 报这类错误，说明索引或行数据结构已损坏，但 MySQL 仍能返回部分结果——这恰恰最危险。表面可用，实际可能：
下一次写入触发崩溃（尤其是 UPDATE/INSERT）
SELECT ... ORDER BY或JOIN突然失败备份时跳过损坏块，导致备份不可用
不要继续写入：暂停应用对该表的所有 DML 操作
先备份现状：用
mysqldump --single-transaction尝试导出（InnoDB）；MyISAM 则需加读锁后拷贝.MYD/.MYI文件区分轻重：若只是索引损坏（
status: OK但提示clients are using or haven't closed the table properly），可尝试REPAIR TABLE ... QUICK；若报record is crashed，必须用REPAIR TABLE ... EXTENDED（MyISAM）或重建（InnoDB）
repair table 执行完显示 “OK”，但业务还是读到脏数据
REPAIR TABLE 成功只代表物理结构恢复了，不代表逻辑一致。尤其当损坏发生在事务中途、或有外键/唯一约束被绕过时：
唯一键重复：修复后可能留下两条相同
email记录，应用 INSERT 会报错，但 SELECT 不报自增 ID 错乱：MyISAM 修复后
AUTO_INCREMENT值可能回退或跳变外键失效：MyISAM 本就不支持外键，InnoDB 表若用强制恢复导出再导入，外键约束需手动重建
修复后必须校验：运行
SELECT COUNT(<em>)</em>对比修复前后；用SELECT FROM t WHERE id IN (1,100,1000)抽样查关键记录内容检查约束：InnoDB 表跑
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 't';确认外键还在MyISAM 表修复后建议执行
ANALYZE TABLE更新统计信息，否则查询计划可能变差
为什么 check table 有时慢得像卡死，甚至超时
CHECK TABLE 默认做完整校验（包括索引树遍历、行 checksum、BLOB 完整性），对大表就是 I/O 密集型操作。尤其在以下情况：
表有多个大 TEXT/BLOB 字段：默认检查全部内容，不是只看指针
使用了压缩行格式（
ROW_FORMAT=COMPRESSED）：解压开销大系统 I/O 负载高，或磁盘响应慢（如机械盘 + RAID5）
加
QUICK参数跳过行数据校验：CHECK TABLE user_logs QUICK;只验证索引结构，快十倍以上加
MEDIUM平衡速度与精度：CHECK TABLE user_logs MEDIUM;校验索引+部分行数据避免在业务高峰跑完整检查；MyISAM 表可先
FLUSH TABLES user_logs;再检查，减少锁等待
MySQL 表损坏修复从来不是“一条命令搞定”的事。真正麻烦的不是命令怎么敲，而是判断损坏类型、选对修复路径、以及修完之后敢不敢信那条 status: OK。
