CHECK TABLE 在 MyISAM 表上能发现索引页指针断裂、数据文件垃圾记录或重复主键、.MYI 与 .MYD 行数不一致、强制中断导致的不完整写入等物理结构损坏，但无法检测语义错误、外键缺失或静默磁盘坏道。
Check Table 在 MyISAM 表上到底能发现什么问题？
CHECK TABLE 对 MyISAM 表不是“预防”数据丢失的工具，而是“暴露已有损坏”的诊断命令。它不会阻止写入、不修复数据、也不触发自动恢复——它只读取索引和数据文件的结构校验和，比对关键元数据（如行数、索引节点数、B-tree 指针连通性）。常见能捕获的问题包括：client is not connected 这类错误不会被它发现，但它可能报出 error: record at X is marked deleted 或 index X is crashed。
- 索引页指针断裂（
index is corrupted） - 数据文件中存在未标记的“垃圾记录”或重复主键
- .MYI 文件头与 .MYD 文件实际行数不一致
- 表被强制中断（如 kill -9 mysqld 进程）后残留的不完整写入
什么时候必须手动运行 CHECK TABLE？
MyISAM 没有 WAL 或崩溃恢复机制，所以以下场景下，CHECK TABLE 是你唯一能快速确认表是否“表面可用”的手段：
- 服务器异常断电或
mysqld被 kill -9 后重启 - 执行过
REPAIR TABLE或OPTIMIZE TABLE后想验证结果 - 从其他服务器拷贝了 .frm/.MYD/.MYI 文件但不确定完整性
- 应用层持续报
Incorrect key file for table或Table is marked as crashed
注意：CHECK TABLE 默认是只读操作，但加 FOR UPGRADE 会尝试升级表格式（极少用），加 EXTENDED 会扫描每行数据（慢，且可能触发磁盘 I/O 高峰）。
为什么 CHECK TABLE 有时返回 OK 却仍出错？
CHECK TABLE 的“OK”仅代表当前校验逻辑未发现结构矛盾，并不等于数据语义正确。例如：
- 某条记录的
created_at字段被误写成 0，但时间戳字段本身格式合法 → 不报错 - 外键约束缺失（MyISAM 本就不支持外键）→ 无法检测关联一致性
- 硬盘坏道导致某块数据读取时静默错误（silent corruption），而校验和恰好未翻转 → 漏检
真正可靠的防护是：定期备份 + 使用 mysqlcheck --check --all-databases 脚本化巡检 + 将 MyISAM 表迁移到 InnoDB（支持事务、行锁、崩溃恢复）。
如何安全地集成 CHECK TABLE 到运维流程？
不要在业务高峰期运行 CHECK TABLE，尤其带 EXTENDED；MyISAM 表会被加读锁，阻塞所有写入。推荐方式：
- 每天凌晨低峰期用
mysqlcheck --check --silent批量检查，配合--log-error=/var/log/mysql/check.log - 脚本中判断返回码：非 0 表示异常，立即触发告警并暂停对该表的写入
- 发现
status: Operation failed后，先REPAIR TABLE tbl_name USE_FRM（慎用，可能丢数据），再CHECK TABLE验证 - 永远保留一份
mysqldump备份后再尝试修复——REPAIR TABLE可能重排数据行，让应用依赖的物理顺序失效
MyISAM 的脆弱性不在检查环节，而在缺乏原子写和日志回放能力。把精力放在迁移方案上，比反复调优 CHECK TABLE 参数更有效。
