CHECK TABLE 在 InnoDB 上默认仅做轻量检查，status: OK 不代表逻辑正确；报错如 error: 1034/1032 多为真实损坏，但 innodb_force_recovery > 0 或 MyISAM 并发写入可能导致误报。
CHECK TABLE 会报哪些错误，怎么判断真问题还是误报
CHECK TABLE 是 MySQL 原生校验表结构与数据页一致性的命令，但它不是万能的——尤其在 InnoDB 表上，默认只做轻量级检查（如页头校验和、索引树基本连通性），不扫描全部数据行。所以你看到 status: OK 不代表数据逻辑正确；而一旦报错，比如 error: 1034（“Found wrong key length”）或 error: 1032（“Can’t find record”），大概率是真实损坏。
常见干扰项：
- InnoDB 表启用
innodb_force_recovery > 0时，CHECK TABLE可能直接跳过或返回status: warning，这不是损坏，是主动降级行为 - MyISAM 表若正在被写入（没加锁），
CHECK TABLE可能报error: 137（“Record file is crashed”），实际只是并发冲突，非物理损坏 - 分区表中某一分区损坏，
CHECK TABLE只提示该分区名，不会自动展开定位到具体子分区
REPAIR TABLE 能修什么，哪些情况它根本不起作用
REPAIR TABLE 对 MyISAM 表有效，可重建索引、修复断裂的数据指针；但对 InnoDB 表，MySQL 8.0+ 已明确禁用该命令（执行会报 ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair）。别试，它不会静默失败，而是立刻拒绝。
即使对 MyISAM，也存在硬限制：
- 数据文件（
.MYD）彻底丢失或被截断，REPAIR TABLE无法恢复丢失内容，只能重建空表结构 - 索引文件（
.MYI）损坏严重时，REPAIR TABLE USE_FRM可强制从.frm文件重建索引，但会丢弃所有现有索引数据，且要求.frm未被修改过 - 使用
myisamchk --safe-recover本地修复比 SQL 方式更可控，尤其当表被锁死或磁盘空间不足时
InnoDB 表真坏了怎么办，别依赖 CHECK/REPAIR
InnoDB 的损坏处理路径和 MyISAM 完全不同：它不提供在线修复命令，核心策略是「隔离 + 替换」。
实操优先级如下：
- 先确认损坏范围：
SHOW ENGINE INNODB STATUS\G查看LATEST FOREIGN KEY ERROR或LATEST DETECTED CORRUPTION段落，定位到具体表空间 ID 和页号 - 尝试
SELECT * FROM table_name LIMIT 1—— 若直接报ERROR 2013 (HY000): Lost connection to MySQL server during query或ERROR 1146 (42S02): Table doesn't exist（但表明明存在），极可能是 ibd 文件头部损坏 - 有备份就立即恢复：用
mysqlpump或mysqldump导出逻辑数据（注意加--single-transaction避免锁表），再导入新实例；无备份则尝试innodb_force_recovery启动（值从 1 递增到 6），配合SELECT INTO OUTFILE抢救还能读出的数据
日常该用什么代替 CHECK TABLE 做预防性检查
靠定期跑 CHECK TABLE 防不了多数问题——它既不触发刷脏页，也不校验主从一致性，更不覆盖事务可见性逻辑。
更实用的做法：
- 开启
innodb_checksum_algorithm = crc32（MySQL 5.6.3+ 默认），让每次页写入都带校验，崩溃后启动时自动检测并报错 - 监控
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads'和Innodb_buffer_pool_read_requests比值，持续高于 5% 说明缓存命中差，IO 压力大，间接增加页损坏概率 - 对关键业务表，每周用
pt-table-checksum（Percona Toolkit）跑一次主从一致性校验，它基于 chunk 分片比对，能准确定位哪一行不一致
InnoDB 的「一致性」本质是事务语义和崩溃恢复能力，不是静态文件校验。把 CHECK TABLE 当成最后手段，而不是日常巡检动作。
