seconds_behind_master不等于真实延迟，因其仅反映sql与io线程时间差且易为null/0；应结合心跳表、gtid差集和运行状态三重校验。
查 Seconds_Behind_Master 不等于延迟真实值
MySQL 的 SHOW SLAVE STATUS 里 Seconds_Behind_Master 是最常被拿来做延迟判断的字段，但它只反映 SQL 线程和 I/O 线程之间的时间差，且在 IO 线程卡住、SQL 线程空闲时会显示 NULL 或 0，造成“假同步”。尤其在 GTID 模式下，主库写入快、从库还没拉取 binlog 时，这个值完全不敏感。
实操建议：
- 不要单独依赖
Seconds_Behind_Master做告警阈值（比如设成 >30 就报警） - 配合
Read_Master_Log_Pos和Exec_Master_Log_Pos手动算位点差，更稳定 - 若用 MySQL 8.0.22+，可查
performance_schema.replication_applier_status_by_coordinator表获取更细粒度任务延迟
用心跳表（heartbeat table）测端到端延迟
这是目前最靠谱的主从延迟检测方式：主库定时更新一张只有时间戳的表（如 mysql_heartbeat），从库读取该时间戳并和本地时间对比。它绕开了复制协议层的黑盒，直接测“数据写入后多久能被查到”，对业务更有意义。
常见错误现象：
- 心跳表没加主键或没建索引，导致从库
SELECT被阻塞，延迟误报 - 主库写入频率太高（如每秒多次
UPDATE），从库积压造成心跳时间戳“跳变” - 应用连接从库时没走只读账号，意外写入心跳表，破坏逻辑
实操建议：
- 建表语句用
CREATE TABLE mysql_heartbeat (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) ENGINE=InnoDB;，单行单表，别加多余字段 - 主库用
INSERT ... ON DUPLICATE KEY UPDATE ts = NOW()更新（需提前插入一行并设主键） - 从库查询必须加
SELECT ts FROM mysql_heartbeat LIMIT 1，避免全表扫描
解析 SHOW SLAVE STATUS 的 Retrieved_Gtid_Set 和 Executed_Gtid_Set
GTID 模式下，Seconds_Behind_Master 失效概率高，真正反映延迟的是两个 GTID 集合的差集大小。只要主库已生成但从库还没执行的事务 ID 数量大，就说明有积压。
使用场景：
- 主从切换前快速评估从库是否“跟得上”
- 排查某次大事务（如
ALTER TABLE）是否卡在从库回放阶段
实操建议：
- 用
SELECT GTID_SUBTRACT(@@global.gtid_executed, Retrieved_Gtid_Set) AS missing_io查缺失的 IO 位点（需先在从库 SET @gtid_executed := @@global.gtid_executed） - 用
SELECT GTID_SUBTRACT(Retrieved_Gtid_Set, Executed_Gtid_Set) AS pending_sql查待执行事务数（结果是 GTID set 字符串，长度可粗略反映积压量） - 注意
Retrieved_Gtid_Set为空时说明 IO 线程异常，不是延迟，是断连
监控脚本别忽略 Slave_SQL_Running_State 和 Slave_IO_Running
很多监控脚本只取 Seconds_Behind_Master，却忽略这两个布尔状态。一旦 Slave_IO_Running: No 或 Slave_SQL_Running_State 卡在 Waiting for dependent transaction to commit，延迟数值就彻底失真——此时不是“慢”，而是“停了”。
性能与兼容性影响：
- MySQL 5.7 中
Slave_SQL_Running_State字段名是State，字段位置也不同，脚本跨版本时容易漏判 - Percona Server 或 MariaDB 的对应字段名/值可能略有差异（如
SQL_Remaining_Delay）
实操建议：
- 监控逻辑必须包含三重校验：
Slave_IO_Running == Yes&&Slave_SQL_Running == Yes&&Seconds_Behind_Master IS NOT NULL AND > N - 对
Slave_SQL_Running_State做白名单匹配，只接受executing、reading event from the relay log这类健康态，其余一律标为异常 - 定期用
SELECT * FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Query'查看是否有长事务阻塞 SQL 线程
延迟检测真正的复杂点不在怎么查，而在于“什么时候该信哪个指标”。Seconds_Behind_Master 看趋势还行，但告警必须结合心跳表 + GTID 差集 + 运行状态三者交叉验证。少一个维度，就容易把“断连”当成“慢”，或者把“大事务回放中”当成“已同步”。
