MySQL主从复制监控关键看五个字段：Slave_IO_Running与Slave_SQL_Running必须同为Yes；Seconds_Behind_Master>60需预警，=0不等于健康；Relay_Log_Space持续增长说明SQL线程阻塞；Last_IO_Errno/Last_SQL_Errno非0须立即处理；GTID模式下还需比对Retrieved_Gtid_Set与Executed_Gtid_Set差集。
MySQL主从复制的性能监控，核心不是看“有没有在跑”，而是看“有没有悄悄掉队、卡住或假连”。只查 Seconds_Behind_Master 为 0，等于用体温计量血压——指标对不上。
怎么看 SHOW SLAVE STATUS 里真正关键的字段
在从库执行 SHOW SLAVE STATUS\G 后，别扫一眼就关，盯死这五个字段：
-
Slave_IO_Running和Slave_SQL_Running：必须同时为Yes；任一为No就已中断，但有时会卡在Connecting状态（网络抖动未超时），看似“运行中”实则没传日志 -
Seconds_Behind_Master：数值 > 60 秒需预警，= 0 不代表健康——如果Relay_Log_Pos长期不更新，而Master_Host又确有写入，说明IO线程假连；若值为NULL，大概率是SQL线程刚启动或已停止，不是“快”，是“没动” -
Relay_Log_Space持续增长且不下降：SQL 线程执行慢或阻塞（如大事务回放、唯一键冲突、DDL 锁表），此时Seconds_Behind_Master可能仍为 0（因还没开始追） -
Last_IO_Errno/Last_SQL_Errno：非 0 必须立刻处理；常见如2003（主库连接失败）、1062（主键冲突）、1146（表不存在），这些错误可能被自动跳过（若配置了slave_skip_errors），导致数据静默不一致
用脚本巡检，但别让脚本本身拖垮数据库
高频查 SHOW SLAVE STATUS 在高负载从库上会争抢 performance_schema 或元数据锁，尤其 MySQL 8.0+ 默认启用大量监控采集器。建议：
- 巡检间隔设为 10–30 秒（
crontab最小粒度是 1 分钟，可用sleep补足；生产环境慎用每秒轮询） - 命令精简为：
mysql -urepl -preplpass -e "SHOW SLAVE STATUS\G" | grep -E "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_IO_Errno|Last_SQL_Errno|Relay_Log_Space"，避免全量输出解析开销 - 异常时优先写本地日志 + 触发告警（如调用企业微信/钉钉 webhook），别依赖邮件——邮件延迟高，且容易进垃圾箱
- 脚本开头加
SELECT CONNECTION_ID()判断连接是否存活，防止因账号过期或权限变更导致误报“复制停止”
用 mysqld_exporter + Prometheus 做趋势监控
人工查或脚本只能发现“此刻是否异常”，但复制性能退化往往是渐进的：比如 Seconds_Behind_Master 从平均 2 秒涨到 15 秒，中间持续 3 小时——人眼根本看不出。这时候需要：
- 部署
mysqld_exporter（v0.15+ 支持 MySQL 8.0 GTID），它把SHOW SLAVE STATUS映射为 Prometheus 指标，如：mysql_slave_status_seconds_behind_master、mysql_slave_status_slave_io_running - Grafana 中建面板，重点画出：
rate(mysql_global_status_commands_total{command="com_commit"}[5m])（主从 QPS 对比）、mysql_slave_status_seconds_behind_master的 95 分位线、mysql_slave_status_relay_log_space_bytes增长斜率 - 告警规则示例：
mysql_slave_status_seconds_behind_master > 120 and avg_over_time(mysql_slave_status_seconds_behind_master[5m]) > 120（连续 5 分钟超阈值，排除瞬时抖动） - 注意：GTID 模式下，仅看
Seconds_Behind_Master不够，要加查Retrieved_Gtid_Set和Executed_Gtid_Set差集，Prometheus 本身不直接暴露该差值，需用mysqld_exporter的mysql_slave_status_gtid_executed和mysql_slave_status_gtid_retrieved自定义计算
最容易被忽略的“假正常”场景
很多 DBA 看到 Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master: 0 就划掉任务，但以下情况正在 silently corrupt 数据：
- 主库开了
log_slave_updates=0（默认值），从库自己产生的变更不会记 binlog —— 级联复制断链，且无法做故障切换后的 binlog 补偿 - 从库设置了
read_only=0，应用误连从库写入，后续主库同 key 写入触发主键冲突，SQL 线程停摆，但 IO 线程照常拉日志，Seconds_Behind_Master反而“稳定为 0” - 使用
STATEMENT格式 binlog，函数如NOW()、UUID()、USER()在从库重放结果不同，导致数据逻辑不一致，但无任何错误码抛出 - 主库
max_allowed_packet设为 64M，从库设为 4M，遇到大事务时 SQL 线程报错Packet too large（错误号 1153），但日志里可能被吞掉，只表现为 Relay Log 停滞
复制性能不是单点指标，是 IO 带宽、SQL 解析效率、磁盘 IOPS、主从时钟偏差、甚至网络 MTU 共同作用的结果。盯住数字，更要理解数字背后那条从 binlog 到 relay log 再到数据页的完整链路——链路上任何一环微小的摩擦，都会在延迟曲线上留下不可逆的刻痕。
