必须连续采样并分析趋势，因单次seconds_behind_master易受大事务、线程卡顿或gtid拉取延迟影响而失真；需结合线程状态、位点差和gtid差集三重校验，pt-heartbeat因端到端测量更可靠。
不能只看单次 Seconds_Behind_Master 值是否大于阈值，必须观察其连续变化趋势——瞬时抖动常见，持续爬升才代表真实积压。
为什么单次检查会误报
很多监控脚本每分钟执行一次 SHOW SLAVE STATUS\G 并取 Seconds_Behind_Master，但这个值本身波动剧烈：
- 主库刚提交一个大事务，从库 SQL 线程还没开始回放，
Seconds_Behind_Master突然跳到 120，2 秒后回落到 0 —— 这是正常脉冲，不是故障 - 从库正在刷脏页或做 checkpoint，
Seconds_Behind_Master暂时卡在 0，但Exec_Master_Log_Pos已停止增长 —— 表面“正常”，实则已卡死 - GTID 模式下，若主库快速生成多个小事务，而从库 IO 线程拉取慢，
Seconds_Behind_Master可能长期为 0（因last_master_timestamp未更新），但Retrieved_Gtid_Set明显落后
用趋势替代快照：三步构建有效监控
真正反映延迟趋势的是「连续多次采样中，值是否单调递增或平台高位维持」。建议用以下逻辑判断：
- 每 5 秒采集一次
Seconds_Behind_Master，保留最近 60 秒（共 12 个点） - 剔除
NULL和负值（说明线程异常），对剩余值做线性拟合：slope = (y12 - y1) / 55 - 若
slope > 0.8（即平均每秒增加近 1 秒）且当前值 > 30，则判定为「上升趋势延迟」；若当前值 > 60 且连续 5 次无下降，判定为「高位滞留延迟」
脚本里最容易漏掉的三个校验点
光读 Seconds_Behind_Master 不够，必须同步验证复制线程状态和位点推进：
- 每次采集前先查
Slave_IO_Running和Slave_SQL_Running是否都为Yes；任一为No，立即告警并退出，不参与趋势计算 - 同时记录
Read_Master_Log_Pos和Exec_Master_Log_Pos，若两者差值持续扩大（比如 30 秒内增长 > 1MB），即使Seconds_Behind_Master是 0，也说明 IO 已滞后 - 在 GTID 模式下，强制补查
SELECT GTID_SUBTRACT(@@global.gtid_executed, Retrieved_Gtid_Set)，结果非空字符串就代表主库有事务没传到从库 —— 这种情况Seconds_Behind_Master经常失真
为什么 pt-heartbeat 的趋势更可信
pt-heartbeat 不依赖 MySQL 内部计时逻辑，而是靠主库写、从库读同一行时间戳，天然具备时间连续性。它的 --monitor 模式每秒打点，输出格式为 2026-05-08T02:05:23.123456 0.18，直接可做斜率分析。而自己写的脚本若用 mysql -e "SHOW SLAVE STATUS\G" 解析，容易因字段顺序变动（如 MySQL 8.0.33 调整了 \G 输出顺序）或空格数量不一致导致解析失败——这种底层脆弱性，比算法误差更致命。
