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 小时——人眼根本看不出。这时候需要：
