大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
主从延迟是DBA绕不过去的坎，但延迟背后的原因，不同的人看到的完全不同。有人遇到延迟就翻慢查询日志，有人一上来就改并行复制参数，还有人选择“重启大法”。折腾一晚上，问题可能解决了，但下次来的时候你还是不知道怎么应对。
从库追不上主库，本质是两条线——主库拼命写，从库拼命回放，看谁跑得快。当从库回放速度跟不上主库的写入速度时，延迟就出现了。前几周我们走完了“发现问题”的路：大事务怎么查、二次放大怎么识别、根因怎么分析。今天走“解决问题”的路——把延迟从秒级压到毫秒级，让从库在主库写入高峰时也能稳稳跟上。
一、回放慢的根源：瓶颈在SQL线程
先走一遍主从复制的基本流程：主库写入 → binlog → 从库IO线程拉取 → relay log → 从库SQL线程重放 → 数据写入。
延迟的瓶颈通常卡在最后一步——SQL线程重放。
主库能同时处理几百上千个并发连接，但MySQL 5.6之前，从库只有一个SQL线程在一条一条地重放binlog。主库是10条流水线同时干活，从库只有1个人在一件一件地做。主库写得越快，从库落得越远。瓶颈就出在“干活的人太少”上。
并行复制就是解决这个问题的。不是所有延迟问题都靠并行复制能解决——并行复制解决“干活的人少”的问题，业务优化解决“活太大”的问题。两个都搞定，从库追不上主库的问题才基本能治好。
二、并行复制的四代演进：选对模式比调对参数更重要
MySQL的并行复制经历了四代演进，每一代的设计思路完全不同。不搞清楚原理就上手调，跟闭眼开车差不多。很多人一开始以为并行复制就是改个slave_parallel_workers的事，结果改完延迟一点没降，还差点搞出数据不一致。
第一代：基于Schema（MySQL 5.6）
如果两个事务操作的是不同数据库，可以并行执行。
slave_parallel_type = DATABASE
slave_parallel_workers = 4
局限性很明显——现在的业务谁不是一个库搞到底？单库多表场景下基本等于没开。
第二代：LOGICAL_CLOCK（MySQL 5.7.2+）
核心思路变了：不再看“是不是同一个库”，而是看“在主库是不是一起提交的”。
MySQL会把多个事务的binlog攒在一起写盘（Group Commit），同一组的事务在主库是“同时”提交的，之间大概率不冲突。5.7在binlog里记录了每个事务的“逻辑时钟”，从库看到逻辑时钟相同的事务就可以并行重放。
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON
单库多表也能并行。但LOGICAL_CLOCK有个问题：逻辑时钟的并行度受限于主库的组提交效率。如果主库并发不高，组里的事务少，从库的并行度也上不去。
第三代：WRITESET（MySQL 5.7.22+）
这是真正的突破——基于行级冲突检测来决定哪些事务可以并行。原理是分析每个事务修改了哪些行，生成一个“写集合”。两个事务如果修改的行没有交集，就可以并行重放，不管它们在主库是不是同一组提交的。
slave_parallel_type = WRITESET
slave_parallel_workers = 8
第四代：WRITESET_SESSION（MySQL 8.0.27+）
在WRITESET的基础上增加了一个限制：同一个session（会话）内的事务仍然按顺序重放。为什么需要这个限制？因为同一个session内的事务可能有业务逻辑上的先后依赖（比如先插入再更新）。WRITESET_SESSION在保证并行度的同时，避免了session内部的数据一致性问题。
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
控制组提交的等待时间。适当调高这个值可以让更多事务被攒到一个组里一起提交，增加并行复制的粒度。
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 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
