Seconds_Behind_Master为NULL或0不能说明复制正常，需同时检查Slave_IO_Running和Slave_SQL_Running是否均为Yes；该值非真实延迟指标，pt-heartbeat才是MySQL 5.7唯一可靠的端到端延迟监控方案。
Seconds_Behind_Master为NULL或0时，复制很可能已中断
看到Seconds_Behind_Master: NULL或0就以为“没问题”，是线上事故最常见诱因。这个值根本不是延迟的晴雨表，而是复制线程协同状态的副产品。
必须同步检查两个关键字段：
-
Slave_IO_Running：为No说明从库连不上主库，或主库binlog被删、权限失效、网络不通 -
Slave_SQL_Running：为No说明SQL线程崩溃了，大概率有Last_SQL_Error，比如主键冲突、表结构不一致、函数不可用
任一为No，Seconds_Behind_Master就完全失去参考价值——它此时显示NULL是常态，显示0反而是误导。
单次查询SHOW SLAVE STATUS不能用于告警判断
MySQL 5.7 的Seconds_Behind_Master本质是「从库当前时间」减去「relay log里最后一条已执行事务的时间戳」再减去主从时钟差。它不反映IO拉取进度，也不感知网络卡顿，更不体现大事务阻塞。
典型误判场景：
- 大事务（如
UPDATE users SET status=1 WHERE id BETWEEN 1 AND 1000000）执行中，Seconds_Behind_Master卡在0长达几十秒，但真实延迟已累积 - IO线程因网络抖动暂停拉取，SQL线程把已有的relay log全执行完了，值显示
0，实际主库新写入的数据一概未到 - 刚
START SLAVE后，clock_diff_with_master只在启动时算一次，若之后主从系统时间被手动调过，该值会持续失真甚至变负
监控脚本必须连续采样：至少每10秒查一次，连续3次≥60秒才触发告警；单次值直接丢弃。
MySQL 5.7并行复制下Seconds_Behind_Master严重滞后于真实延迟
启用slave_parallel_workers > 0后，Seconds_Behind_Master只取「最慢worker线程」的last_master_timestamp来计算，其他worker跑得再快也拉不动这个数字。
这意味着：
- 即使9个worker都已追平，只要第10个还在等锁，整个指标就卡在高位
- 它无法反映整体吞吐瓶颈，更无法告诉你“还有多少事务没开始执行”
- 必须配合
performance_schema.replication_applier_status_by_coordinator查各worker的APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP和积压量
别信SHOW SLAVE STATUS里那个单一数字——它在并行模式下就是个“最差体验代表”，不是平均值，也不是中位数。
pt-heartbeat是MySQL 5.7唯一能落地的端到端延迟方案
自建脚本轮询Seconds_Behind_Master在测试环境能跑通，但在生产中扛不住真实压力：跨机房延迟、主从切换、GTID模式、级联复制都会让它失效。真正可靠的方案只有一个：pt-heartbeat。
它不依赖MySQL内部统计逻辑，而是：
- 在主库用
INSERT ... ON DUPLICATE KEY UPDATE ts = NOW()每秒更新一张单行心跳表 - 从库读取该
ts字段，与本地NOW()做差，结果就是业务可感知的真实延迟 - 建表必须带主键：
CREATE TABLE heartbeat (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY(ts))
注意：心跳表不能走普通应用账号，必须用只读专用账号连接从库；主库写入频率别设太高（建议1秒1次），否则从库SELECT可能被锁住，反而制造假延迟。
