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_runningGrafana 中建面板，重点画出：
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 再到数据页的完整链路——链路上任何一环微小的摩擦，都会在延迟曲线上留下不可逆的刻痕。
