mysqlcheck 不能查主从延迟或连接数爆满，它仅校验表结构和数据页一致性，不涉及复制状态或服务器连接参数。
mysqlcheck 能不能直接查出主从延迟或连接数爆满
不能。mysqlcheck 只负责表结构和数据页层面的校验与修复，它不接触网络层、复制线程或服务器状态。主从延迟得看 Seconds_Behind_Master，连接数问题得查 Threads_connected 和 max_connections 配置。
常见错误现象：有人在监控脚本里只跑 mysqlcheck -c 就以为“数据库健康了”，结果第二天主库 OOM 或从库追不上，才发现漏了关键指标。
-
mysqlcheck的作用域仅限于存储引擎（InnoDB/MyISAM）的数据一致性 - 它不读取 binlog position，不检查 relay log 是否中断
- 执行时会加表级锁（MyISAM）或意向锁（InnoDB），高流量期间可能阻塞写入
用 mysqlcheck 检查表损坏的正确姿势
核心是分场景选参数，不是无脑 mysqlcheck -a。默认行为对 InnoDB 表基本无效——因为 InnoDB 自己做崩溃恢复，mysqlcheck -c 对它的校验只是检查 .frm 文件和表定义是否可加载，不碰实际数据页。
使用场景：怀疑磁盘静默错误、异常断电后 MyISAM 表索引错乱、或者迁移后发现 COUNT(*) 和 SELECT 结果不一致。
- MyISAM 表必须用
mysqlcheck -c -r（-c校验 +-r修复），单独-c只报 “OK” 或 “error”，不输出具体坏块位置 - InnoDB 表建议用
mysqlcheck -c --extended，它会触发ANALYZE TABLE和部分元数据扫描，比默认更严格，但仍不如innochecksum直接验数据文件 - 避免在业务高峰期运行
-r，MyISAM 修复过程会锁整个表，InnoDB 虽支持在线 DDL，但mysqlcheck -r不走在线路径
修复失败时常见的三个硬坑
报错就停、不看上下文，是 mysqlcheck 使用中最容易翻车的地方。尤其当提示 “Error 1034” 或 “Error 1036” 时，表面是索引/表只读，根因往往藏在别处。
-
ERROR 1034 (HY000) at line 1: Incorrect key file for table 'xxx'; try to repair it：大概率是/tmp空间不足，mysqlcheck -r重建索引需要临时空间，不是表本身坏了 -
ERROR 1036 (HY000) at line 1: Table 'xxx' is read only：先确认read_only=ON是否开启，再检查文件系统是否只读（mount | grep " /var/lib/mysql "），而不是急着改表权限 - 修复后
SELECT仍报ERROR 2013 (HY000): Lost connection to MySQL server during query：说明表已损毁到 InnoDB buffer pool 无法加载，mysqlcheck无能为力，得靠备份恢复或innodb_force_recovery导出数据
要不要把 mysqlcheck 加进每日巡检脚本
可以加，但必须带条件和超时控制。全库扫一遍 mysqlcheck -c 在几百张表的实例上可能跑十几分钟，且对 I/O 是尖峰压力。
性能影响明显：单次执行会触发大量随机读，尤其对机械盘；并发多个 mysqlcheck 进程可能打满 IO wait。
- 只检查核心业务库，跳过日志库、统计宽表等非关键库（用
--databases db1 db2显式指定） - 加上
--timeout=300（单位秒），防止某张大表卡死整个脚本 - 避开凌晨备份窗口，也避开每小时整点（很多监控系统也在刷 SHOW GLOBAL STATUS）
- 修复操作（
-r）绝不能放进自动脚本，必须人工确认后再执行
真正容易被忽略的是：mysqlcheck 的退出码只有 0（成功）、1（警告）、2（错误）。但有些“警告”比如 “The storage engine for the table doesn’t support repair”，其实是该表根本修不了——脚本里只判非零就告警，反而会掩盖真正要人看的日志。
