Seconds_Behind_Source 变大时，只说“从库慢了”太粗。主从延迟不是单点问题，而是源库提交进度和副本应用进度之间的差距，可能积压在传输、relay log、调度、重放或提交确认任何一段。
排查主从延迟，要先定位队列在哪里变长，再判断是大事务、热点冲突、并行度不足、网络抖动，还是从库自身资源不够。不同位置的处理方式完全不同。
先把机制边界说清楚
主从延迟是源库提交进度和副本应用进度之间的差距。它不是单一指标，而是复制链路每一段排队时间的总和：binlog 生成、网络传输、relay log 写入、事务调度、SQL 重放、提交确认都可能贡献延迟。
整体路径
上面这张图先看粗线条：宏观上，延迟链路可以拆成两个队列：I/O 队列负责把源库 binlog 拉到副本，应用队列负责把 relay log 变成副本数据。I/O 追不上时，副本拿不到日志；应用追不上时，relay log 越堆越多。定位时必须先判断是哪一个队列在涨。
底层流程
底层拆解先看数据结构。「主从延迟」至少涉及下面几类结构：
- 复制位点：描述源库已发送和副本已执行到哪里。
- relay log 队列：保存已拉取但未应用的事件。
- coordinator：多线程复制下负责分发事务。
- worker：并行应用事务的执行线程，受依赖关系和提交顺序约束。
再看完整执行流程：
- 源库持续提交事务并生成 binlog。
- 副本 I/O 线程拉取 binlog，更新接收位点。
- relay log 中待应用事件形成队列。
- SQL 应用线程按依赖关系执行事务。
- 大事务、锁等待或资源不足导致应用位点落后。
取舍与边界
版本差异上，MySQL 5.7 支持基于库或 logical clock 的并行复制。MySQL 8.0 增强了写集合依赖跟踪等能力，让更多事务可以并行应用；但如果业务本身集中更新同一热点行或同一张大表，并行复制也会被依赖关系限制。
主从延迟最容易误判的地方是指标滞后和语义模糊。Seconds_Behind_Source 只能反映某种时间差，不能直接告诉你是网络、磁盘、锁还是单线程应用导致；复制线程显示 running，也不等于副本已经追平。
典型问题：用机制化例子排查
主从延迟可以先当成队列问题：binlog 生成、传输、relay log、调度和重放，任何一段积压都会反映成副本落后。先定位队列，再谈优化。
可以落到这些动作：
- 先分辨 IO 延迟和 SQL 应用延迟，分别看接收位点、执行位点和 relay log 积压。
- 控制大事务和长事务，避免一个事件堵住后续所有回放。
- 根据业务写入模式开启并调优并行复制，但不要期待它解决热点冲突。
- 读写分离层接入延迟阈值，超过阈值时摘除从库或降级到主库读。
收束：延迟是队列变长
主从延迟是异步系统的排队问题。真正的治理不是盯一个秒数，而是让每一段队列可观测、可限流、可降级。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MySQL」，欢迎关注公众号 「十三Tech」。后续会继续按机制、图解和实战排查这条线更新。
