MySQL主从延迟的“最后一公里”：如何把延迟压到极限

关键词：主从延迟；并行复制；WRITESET；LOGICAL_CLOCK；从库优化；RPO

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

主从延迟是DBA绕不过去的坎，但延迟背后的原因，不同的人看到的完全不同。有人遇到延迟就翻慢查询日志，有人一上来就改并行复制参数，还有人选择"重启大法"。折腾一晚上，问题可能解决了，但下次来的时候你还是不知道怎么应对。

从库追不上主库，本质是两条线------主库拼命写，从库拼命回放，看谁跑得快。当从库回放速度跟不上主库的写入速度时，延迟就出现了。前几周我们走完了"发现问题"的路：大事务怎么查、二次放大怎么识别、根因怎么分析。今天走"解决问题"的路------把延迟从秒级压到毫秒级，让从库在主库写入高峰时也能稳稳跟上。

一、回放慢的根源：瓶颈在SQL线程

先走一遍主从复制的基本流程：主库写入 → binlog → 从库IO线程拉取 → relay log → 从库SQL线程重放 → 数据写入。

延迟的瓶颈通常卡在最后一步------SQL线程重放。

主库能同时处理几百上千个并发连接，但MySQL 5.6之前，从库只有一个SQL线程在一条一条地重放binlog。主库是10条流水线同时干活，从库只有1个人在一件一件地做。主库写得越快，从库落得越远。瓶颈就出在"干活的人太少"上。

并行复制就是解决这个问题的。不是所有延迟问题都靠并行复制能解决------并行复制解决"干活的人少"的问题，业务优化解决"活太大"的问题。两个都搞定，从库追不上主库的问题才基本能治好。

二、并行复制的四代演进：选对模式比调对参数更重要

MySQL的并行复制经历了四代演进，每一代的设计思路完全不同。不搞清楚原理就上手调，跟闭眼开车差不多。很多人一开始以为并行复制就是改个slave_parallel_workers的事，结果改完延迟一点没降，还差点搞出数据不一致。

第一代：基于Schema（MySQL 5.6）

如果两个事务操作的是不同数据库，可以并行执行。

bash 复制代码

slave_parallel_type = DATABASE
slave_parallel_workers = 4

局限性很明显------现在的业务谁不是一个库搞到底？单库多表场景下基本等于没开。

第二代：LOGICAL_CLOCK（MySQL 5.7.2+）

核心思路变了：不再看"是不是同一个库"，而是看"在主库是不是一起提交的"。

MySQL会把多个事务的binlog攒在一起写盘（Group Commit），同一组的事务在主库是"同时"提交的，之间大概率不冲突。5.7在binlog里记录了每个事务的"逻辑时钟"，从库看到逻辑时钟相同的事务就可以并行重放。

bash 复制代码

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON

单库多表也能并行。但LOGICAL_CLOCK有个问题：逻辑时钟的并行度受限于主库的组提交效率。如果主库并发不高，组里的事务少，从库的并行度也上不去。

第三代：WRITESET（MySQL 5.7.22+）

这是真正的突破------基于行级冲突检测来决定哪些事务可以并行。原理是分析每个事务修改了哪些行，生成一个"写集合"。两个事务如果修改的行没有交集，就可以并行重放，不管它们在主库是不是同一组提交的。

bash 复制代码

slave_parallel_type = WRITESET
slave_parallel_workers = 8

第四代：WRITESET_SESSION（MySQL 8.0.27+）

在WRITESET的基础上增加了一个限制：同一个session（会话）内的事务仍然按顺序重放。为什么需要这个限制？因为同一个session内的事务可能有业务逻辑上的先后依赖（比如先插入再更新）。WRITESET_SESSION在保证并行度的同时，避免了session内部的数据一致性问题。

bash 复制代码

slave_parallel_type = WRITESET_SESSION
slave_parallel_workers = 8

三、并行度调优：worker数不是越大越好

slave_parallel_workers设多少合适？很多人的第一反应是"越多越好"。但实际情况是：worker太多，线程切换和锁竞争的开销反而会拖慢回放速度。

调优原则：

CPU核心数	推荐worker数	说明
4核	4-8	保守起步
8核	8-16	通常最优区间
16核	16-32	高配场景
32核以上	不超过32	超过32收益递减

调优步骤：

先设slave_parallel_workers = 8，观察一周
看从库CPU使用率和延迟趋势：
- CPU低于60%且延迟还在涨 → 加worker
- CPU高于80%或锁争用明显 → 减worker

slave_preserve_commit_order要不要开？

这个参数保证从库事务的提交顺序与主库一致。开启后会稍微降低并行度，但能避免数据不一致的风险。生产环境建议保持ON。

四、精细化参数调优

并行复制调好了，但延迟还是压不下去，问题可能出在binlog和刷盘参数上。

1. binlog_format = ROW

一定要用ROW格式。虽然STATEMENT格式省空间，但无法准确记录行级变化，容易导致主从数据不一致，而且对并行复制的支持不如ROW好。

2. binlog_group_commit_sync_delay

控制组提交的等待时间。适当调高这个值可以让更多事务被攒到一个组里一起提交，增加并行复制的粒度。

bash 复制代码

binlog_group_commit_sync_delay = 1000  # 微秒

建议从0开始逐步调高，观察延迟变化。

3. 从库硬件配置不低于主库

从库硬件配置最好不低于主库，尤其是磁盘I/O。很多团队用淘汰下来的旧机器跑从库，延迟问题从第一天就埋下了。

五、业务侧与架构侧配套优化

并行复制和参数调优是"治标"，业务优化才是"治本"。

1. 拆分大事务

并行复制解决"干活的人少"的问题，业务优化解决"活太大"的问题。一个事务里更新了50万行，worker再多也得等它跑完。拆分大事务是最有效的预防手段。

2. 读写分离路由做对

不是所有查询都应该去从库。实时性要求高的查询（如订单详情、余额查询）走主库，容忍秒级延迟的查询（如报表、历史记录）走从库。

3. 监控不要只看Seconds_Behind_Master

Seconds_Behind_Master的盲区我们前几周已经讲过了。建议补充监控：

从库的binlog应用延迟（Read_Master_Log_Pos与Exec_Master_Log_Pos的差值）
从库CPU使用率
worker线程的活跃状态

六、总结

把从库延迟压到极限，需要做四件事：

层级	动作	目标
复制模式	升级到WRITESET或WRITESET_SESSION	最大化并行度
并行度调优	worker数=CPU核数的70%-100%，动态调整	不浪费CPU，不引入锁竞争
参数精细化	ROW格式、调优group commit、从库硬件不低于主库	减少每一环节的额外开销
业务配套	拆分大事务、读写分离路由、完善监控	从源头减少延迟压力

主从延迟优化的终点不是"延迟降到0"，而是"延迟可控、可预测、可接受"。把上面四件事做到位，你的从库在主库写入高峰时也能稳稳跟上。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽......我们下次见~