seconds_behind_master显示0不代表无延迟，而是指标失效；其计算依赖主从时钟同步、sql线程正在执行的事件时间戳及io线程是否已拉取binlog，任一环节异常（如ntp未对齐、大事务阻塞、io滞后）都会导致失真。
Seconds_Behind_Master 显示 0，但业务查不到新数据？
这不说明没延迟，只说明监控指标失效了。Seconds_Behind_Master 的计算依赖主从系统时间差和当前正在回放的事件时间戳，一旦主从 NTP 未对齐、SQL 线程卡在大事务里、或 IO 线程还没把 binlog 拉完，这个值就完全失真。它可能长时间停在 0，也可能突然跳到几百秒——不是延迟“发生了”，而是你终于“看见”了。
大事务是主从延迟最隐蔽的元凶
主库一个 UPDATE orders SET status='done' WHERE create_time 跑了 28 秒，binlog 写入一条巨型 event；从库 SQL 线程必须单线程完整执行完这 28 秒，期间无法处理后续任何事务。这不是“慢”，是“堵死”。
- ROW 格式下，百万行更新会生成百万级 binlog event，放大回放压力
- 即使启用了 MTS（
slave_parallel_workers > 0），大事务仍会被强制串行回放 - DDL 如
ALTER TABLE同样被当作大事务处理，且常伴随 MDL 锁阻塞
从库性能短板直接拖垮复制链路
很多人默认“从库只读不写，配低点没事”，结果发现：主库用 NVMe SSD + 32 核，从库却是 SATA 盘 + 4 核虚拟机。当主库每秒写入 2000 条变更，从库磁盘 IO 跑满、CPU 持续 95%，relay log 就开始堆积，Relay_Log_Space 指标会明显上涨。
-
SHOW SLAVE STATUS中Read_Master_Log_Pos和Exec_Master_Log_Pos差距持续扩大 → IO 或 SQL 层已积压 - 从库执行
SHOW PROCESSLIST出现大量State: Reading event from the relay log→ SQL 线程忙不过来 - 备份任务（如
mysqldump --single-transaction）触发FLUSH TABLES WITH READ LOCK→ 直接卡住 SQL 线程
网络和配置细节常被忽略
跨机房同步时，看似带宽充足，但 RTT 达到 5ms，而主库每毫秒生成多个事务，从库 IO 线程频繁等待 ACK，实际吞吐远低于理论值。更隐蔽的是：slave_compressed_protocol=0（默认关闭）、binlog_format=STATEMENT（导致从库函数执行偏差引发重试）或半同步未启用却误判为“强一致”。
- 用
iperf -c 主库IP -p 5201 -t 60实测有效带宽，别信云厂商标称值 -
slave_parallel_type=LOGICAL_CLOCK必须配合slave_parallel_workers > 0才生效，且仅对无冲突事务起作用 - GTID 模式下，用
SELECT GTID_SUBTRACT(@@global.gtid_executed, @@global.gtid_retrieved)查真实未应用事务数，比Seconds_Behind_Master可靠得多
