MySQL 主从延迟从哪来：复制链路三段排查

直接答案：主从延迟的本质是"从库回放的速度赶不上主库生产的速度"。这条复制链路分三段——主库生产、传输、从库回放，延迟必然卡在其中一段：要么主库同一秒写入量太大，要么传输断断续续，要么从库单线程回放追不动。排障就顺着这三段找。

第一段：主库瞬间写了太多

大事务是延迟的头号来源：一条更新几十万行的批量任务、一次全表数据修正，主库几十秒执行完，从库回放同样要几十秒——这期间的落差全计成延迟。判别方法：看延迟是否与批量任务时间点吻合，报表任务、夜间批处理一跑延迟就蹿，基本就是大事务。治理方向是把大事务拆小（分批提交），从源头削峰。

第二段：网络传输不稳

跨机房、跨公网专线的主从，传输抖动直接变成延迟。这一段相对好查：主备之间带宽占用、丢包率、复制线程是否频繁重连，日志里 IO 线程反复报错就是传输段的证据。同机房部署基本可排除此段，跨机房的延迟问题先查线再查库。

第三段：从库回放追不动

最常见的一段。回放的瓶颈通常有三处：从库机器规格低于主库（主库写完就算了，从库还要认真执行）、从库还背着读查询的重负载（业务把读全压到从库，回放资源被抢）、以及复制回放的并发能力不足（传统单线程回放遇到多并发写入就是排队）。治理依次是：从库规格对齐主库、读写分离做好负载控制、按版本启用并行的复制回放能力——三招下来，回放速度通常上一个台阶。

监控与预期管理

延迟要持续记录曲线而不是出事才看：正常水位是多少、批量任务时段允许多少，心里有数才能识别异常。业务侧也要有预期：读写分离架构下"刚写完立刻读"天然有窗口，对一致性敏感的读走主库，这不是故障是架构特性。

主从延迟不是玄学，是三段里某段的产能问题。贵州诚鑫致达科技为客户做数据库主从部署时，从库规格对齐、大事务拆分规范、延迟曲线监控三项进交付基线——延迟曲线平了，读写分离的架构红利才真正落袋。

企业存储选型参考｜贵州诚鑫致达

用 DS918+/DS920+/DS1517+/DS1817+ 等经典机型的老用户，群晖机型参考：可平滑升级到 DS1522+ · DS1823xs+ · DS2422+。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。