check table 是最轻量安全的表损坏初判方式，myisam 加读锁、innodb 基本无锁；关键看 msg_type 是否为 error 或 warning，status=ok 不代表绝对正常。
怎么用 CHECK TABLE 快速判断表是否损坏
直接运行 CHECK TABLE 是最轻量、最安全的初步诊断方式，它不锁表（MyISAM 会加读锁，InnoDB 基本无锁），适合线上环境快速探查。它返回的结果里关键看 Msg_type 列：出现 error 或 warning 就得进一步处理，status 显示 OK 并不绝对代表没问题——比如某些索引逻辑错误可能被忽略。
- 对单表检查：
CHECK TABLE mydb.users; - 批量检查多个表：
CHECK TABLE mydb.users, mydb.orders, mydb.logs; - 加
EXTENDED参数会做更彻底扫描（比如校验每行数据结构），但耗时明显增加，建议只在怀疑深层损坏时用：CHECK TABLE mydb.users EXTENDED; - MyISAM 表默认检查快，InnoDB 表实际是走
INFORMATION_SCHEMA.INNODB_SYS_TABLES和页校验逻辑，响应时间略长但更侧重一致性
CHECK TABLE 报 error 后该不该直接 REPAIR TABLE
不能无脑修。InnoDB 表根本不支持 REPAIR TABLE，强行执行会报错 ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't support repair；MyISAM 才能修，但修复前必须确认：表没被其他进程写入，且你有完整备份。否则修坏的风险比停机还高。
- 先确认引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='mydb' AND TABLE_NAME='users'; - MyISAM 表修复命令：
REPAIR TABLE mydb.users;（可加QUICK跳过排序，或EXTENDED强制重建索引） - InnoDB 表遇到
error，优先考虑mysqldump导出 + DROP + 重建，或使用ALTER TABLE ... IMPORT TABLESPACE（需提前有 .ibd 文件和元数据备份） - 如果
CHECK TABLE返回Msg_text是Table is marked as crashed，基本确定 MyISAM 表头损坏，这时REPAIR TABLE是标准动作
为什么 CHECK TABLE 有时显示 OK 却还是查不到数据
因为 CHECK TABLE 主要验证物理结构和索引一致性，并不校验业务逻辑或外键约束是否生效。常见真问题包括：索引失效导致 WHERE 条件走全表扫描却没结果、统计信息陈旧让优化器选错执行计划、或者表里根本没满足条件的数据——这些都不会触发 CHECK TABLE 报错。
- 查执行计划：
EXPLAIN SELECT * FROM users WHERE id = 123;看key和rows是否合理 - 强制更新统计信息：
ANALYZE TABLE users;（InnoDB 下尤其有用） - 检查数据是否存在：
SELECT COUNT(*) FROM users WHERE id = 123;，别只信应用层返回空 - 注意字符集/排序规则隐式转换，比如
utf8mb4_bin和utf8mb4_0900_as_cs比较行为不同，也可能导致“查不到”假象
生产环境执行 CHECK TABLE 的几个硬约束
它不是“随便跑跑就没事”的命令。大表上执行可能引发 I/O 尖峰，尤其加了 EXTENDED；某些云数据库（如阿里云 RDS、AWS RDS）会限制该命令权限，或自动拒绝超过阈值的表检查。
- 避开业务高峰，尤其是检查 >10GB 的表
- 监控
SHOW PROCESSLIST中状态是否长时间卡在checking table - RDS 用户需确认账号有
PROCESS权限，且实例参数innodb_checksum_algorithm不为none（否则 InnoDB 校验跳过） - 如果表用了压缩（
ROW_FORMAT=COMPRESSED），CHECK TABLE会解压校验，内存消耗翻倍，容易 OOM
真正麻烦的不是命令怎么敲，而是看到 OK 就以为万事大吉，或者把 InnoDB 当 MyISAM 一样去修——这两点最容易拖慢故障定位节奏。
