主从延迟本质是复制链路某段卡住，九成因SQL线程回放慢而非IO拉取慢；Seconds_Behind_Master常不准，因仅反映当前event时间戳差，遇大事务、网络中断或半同步降级即失效，须结合日志位点比对及pt-heartbeat实测。
主从延迟不是“慢”，而是复制链路中某一段卡住了。绝大多数情况是 SQL_Thread 回放跟不上，而不是网络拉不到日志。
Seconds_Behind_Master 为什么经常不准
这个值只反映当前正在执行的 binlog event 和主库最新时间戳的差值，但有三类典型失效场景：
- 主库大事务提交后，从库
SQL_Thread还在回放中，Seconds_Behind_Master会突然归零（因为 event 时间戳没更新），但 relay log 里堆着几百万行没执行 - 网络中断时，
IO_Thread停摆，Seconds_Behind_Master也会归零——监控显示“绿灯”，实际已彻底脱节 - 半同步超时降级为异步后，
Seconds_Behind_Master不再反映写入安全水位，仅表“回放进度”
所以别单看它。必须配合 Master_Log_File/Read_Master_Log_Pos 和 Relay_Master_Log_File/Exec_Master_Log_Pos 对比，确认 IO 和 SQL 是否真正追平。
如何快速定位是拉取慢还是回放慢
执行 SHOW SLAVE STATUS\G 后重点看这四组字段：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果
Master_Log_File == Relay_Master_Log_File且Read_Master_Log_Pos == Exec_Master_Log_Pos→ 两端完全一致，无延迟 - 如果
Read_Master_Log_Pos → 不可能，说明状态异常（一般是解析错误或 relay log 损坏） - 如果
Read_Master_Log_Pos远大于Exec_Master_Log_Pos→IO_Thread拉得快，SQL_Thread跑不动，问题在回放 - 如果
Read_Master_Log_Pos接近Exec_Master_Log_Pos，但都远小于主库Position→IO_Thread拉取滞后，查网络、磁盘 IO 或主库 dump 线程压力
再补一句：用 pt-heartbeat 打点写入主库并读取从库时间差，才是真实延迟。它绕过了 MySQL 内部状态计算逻辑，直接测端到端数据可见性。
回放慢的三个高频根因和对应动作
90% 的线上延迟爆发都来自以下三类，顺序排查效率最高：
-
大事务阻塞：主库执行了
DELETE FROM huge_table WHERE ...，从库单线程必须等它全部跑完才能处理后续事务。查SHOW PROCESSLIST中SQL_Thread状态是否长期卡在Updating或Deleting -
DDL 锁等待：主库跑了
ALTER TABLE，从库SQL_Thread在等metadata lock，此时SHOW PROCESSLIST里能看到Waiting for table metadata lock。注意：这类锁不会出现在information_schema.INNODB_TRX里 -
无主键表写入：ROW 格式下，没有主键或唯一键的表更新，MySQL 无法做行级并行判断，强制退化为单线程串行回放。检查
SHOW CREATE TABLE，确保所有被频繁写的表都有显式主键
真正难搞的是那种“平时 50ms，每小时尖刺到 40s”的延迟抖动——大概率是定时任务触发了隐式大事务，或者备份脚本悄悄加了 FLUSH TABLES WITH READ LOCK。这种必须结合 cron 日志和 slow_query_log 时间戳交叉比对。
