SQL 主从延迟本质是主库写入速度超过从库日志拉取与重放速度，链路含 binlog 写入、dump 发送、IO 接收写 relay log、SQL 线程读取、执行事务五步；任一环节卡顿均致延迟累积，主库顺序写高效，从库 SQL 线程随机 IO 开销大，高并发或大事务易堵塞，需开启并行回放并优化硬件网络，监控应关注延迟趋势而非仅 Seconds_Behind_Master。
SQL 主从延迟，本质是主库写入速度超过了从库拉取和重放日志的速度。整个复制链路分五步：主库写 binlog → 主库 dump 线程发送 → 从库 IO 线程接收并写入 relay log → 从库 SQL 线程读 relay log → 从库执行事务更新数据。任一环节卡住或变慢，都会导致延迟累积。
主库写得快，但从库回放跟不上
主库的 binlog 是顺序写，效率高；而从库 SQL 线程执行 DML/DDL 是随机 IO，还要加锁、查索引、刷脏页，开销大得多。尤其当主库并发高（比如批量导入、活动峰值），单线程 SQL 回放根本处理不过来，relay log 就开始堆积。
大事务或 DDL 操作会强制串行化
一个大事务更新跨多个表、上万行，或者一次 ALTER TABLE，主库会把它作为一个完整 event 写进 binlog。从库必须等这个事务完全执行完，才能继续下一个——期间所有后续事务都得排队。这时 Seconds_Behind_Master 可能跳涨几十分钟，不是因为慢，而是被“堵死”了。
并行能力没打开，白白浪费资源
MySQL 5.7 默认支持基于组提交的并行回放，8.0 进一步用 writeset 判断事务间是否冲突。但前提是：主库开启 binlog_transaction_dependency_tracking = WRITESET，从库设 slave_parallel_type = LOGICAL_CLOCK 或 WRITESET，并调高 slave_parallel_workers（比如 8 核设 12）。否则默认仍是单线程。
硬件与网络拖了后腿
从库磁盘还是机械盘、buffer pool 太小、内存不足导致频繁刷脏页；主从跨机房部署、RTT 超过 5ms、带宽被其他业务占满；甚至从库开着 log_slave_updates 做级联复制，额外多写一遍 binlog——这些都会让原本就吃紧的同步链路雪上加霜。
监控值容易误判，别只盯 Seconds_Behind_Master
这个值为 0 不代表没延迟：主库停写时它归零；IO 线程断连时它可能卡在 0；GTID 模式下更应看 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 的差值，或用 SELECT MASTER_POS_WAIT() 实测追平点。真正要关注的是趋势——持续爬升、突增、抖动，比单个数字更有诊断价值。
