CHECK TABLE 默认对InnoDB仅校验元数据，需加EXTENDED才深度检查页数据；结果中Msg_type为error或warning才需关注，非“OK”即安全。
MySQL 中 CHECK TABLE 命令怎么执行才有效
直接在 mysql 客户端里运行 check table 不等于“查完了”，它只对某些存储引擎（如 myisam）做物理校验，对 innodb 默认只检查表结构和元数据一致性，不扫描实际页数据——除非你加了 extended 或 fast 等选项。
实操建议：
- 先确认表引擎：
SHOW CREATE TABLE `your_table`;，InnoDB表别指望默认行为能发现页损坏 - 对
InnoDB想做深度检查，必须显式加EXTENDED：CHECK TABLE your_table EXTENDED; - 大表慎用
EXTENDED：会锁表（取决于 MySQL 版本和隔离级别），且可能触发大量磁盘 I/O，线上环境建议低峰期执行 - 如果只是想快速确认是否可访问、无元数据损坏，用
FAST更轻量：CHECK TABLE your_table FAST;
CHECK TABLE 的返回结果怎么看懂关键字段
命令执行后返回一个结果集，不是日志也不是纯文本。真正有用的只有三列：Table、Op、Msg_type、Msg_text。重点盯住 Msg_type 是 error 还是 warning，而不是扫一眼 “OK” 就以为没事。
常见错误现象：
-
Msg_type = 'error'且Msg_text含corrupt或index is crashed：说明物理损坏已确认，不能仅靠REPAIR TABLE（InnoDB不支持该命令） -
Msg_type = 'warning'且Msg_text提到Row size too large或Incorrect key file：多为索引统计信息偏差或临时写入问题，不一定影响查询，但需结合SHOW WARNINGS看完整上下文 - 返回
status行中Msg_text是OK，但前面有warning：这种“带警告的 OK”最容易被忽略，实际代表结构异常（比如外键定义失效但未报错）
为什么 CHECK TABLE 在从库上经常报 Waiting for table flush
这不是检查本身的问题，而是命令执行前隐式请求了 FLUSH TABLES WITH READ LOCK（尤其在 MyISAM 表或老版本 MySQL 中），导致它卡在等待全局读锁上——而从库可能正卡在某个慢 SQL 或复制延迟的 relay log 应用中。
使用场景与绕过方式：
- 主库上执行一般没问题；从库上优先用
FOR UPGRADE（MySQL 5.7+）代替EXTENDED，它不加全局锁 - 确认从库没延迟：
SHOW SLAVE STATUS\G查看Seconds_Behind_Master，非 0 时别硬跑CHECK TABLE - 若必须检查从库，先停复制：
STOP SLAVE;，再执行，完事再START SLAVE;——但注意这会拉长复制延迟 - Percona Server 或 MariaDB 用户可考虑
pt-table-checksum替代，它基于分块校验，不锁表
CHECK TABLE 和 mysqlcheck 选哪个更可控
mysqlcheck 是客户端工具，底层调的还是 CHECK TABLE，但它封装了批量操作和自动重连逻辑，对运维批量巡检更友好；而直接在 MySQL 客户端里执行 CHECK TABLE 更利于调试单表、观察实时状态。
参数差异与性能影响：
-
mysqlcheck -c默认对所有表逐个执行CHECK TABLE，但不会并行；加--parallel=4可并发，但要注意连接数限制和服务器负载 -
mysqlcheck --extended等价于 SQL 层的CHECK TABLE ... EXTENDED，同样对大InnoDB表耗时明显 - 如果表名含特殊字符或大小写敏感，
mysqlcheck默认会把库名转小写，导致找不到表——此时必须加--skip-quote-names并手动指定正确大小写 - 用
mysqlcheck时，错误输出混在 stdout 里，容易漏掉 warning；建议始终加-v并配合2>&1 | grep -E "(error|warning)"抽取关键行
真正难的不是执行命令，是判断“报什么错该立刻止损”“什么 warning 可以排队处理”。比如 InnoDB 表出现 page corruption，意味着备份可能也已失效——这时候检查动作本身，只是故障响应的第一步。
