之前我们深入探讨过主从同步失败的五大诱因，有读者追问：从库并未宕机，但 Seconds_Behind_Master 持续卡在几千秒，延迟越拖越大，该如何应对？

这个场景非常典型。很多人误以为并行复制只是改个参数那么简单——设置一个 slave_parallel_workers 就万事大吉。结果调整后延迟纹丝不动，甚至险些引发数据不一致。后来才明白，MySQL 的并行复制经历了四代演进，每一代的设计理念截然不同，参数之间还有依赖关系。不了解原理就盲目调优，无异于闭眼开车。

本文从单线程为何缓慢讲起，拆解四代演进的细节，并配套排查路径与调优方案，力求让读者看完就能落地实践。

一、为什么从库会“追不上”主库？

先回顾一下主从复制的基本流程：

主库写入 → binlog → 从库IO线程拉取 → relay log → 从库SQL线程重放 → 数据写入

延迟就卡在最后一步：SQL线程重放。

主库能够同时处理几百上千个并发连接，binlog 里记录的是所有连接混合在一起的事务。但从库呢？MySQL 5.6 之前，只有一个 SQL 线程在一条一条地重放。

打个比方：主库是10条流水线同时干活，从库只有1个人在逐件操作。主库写入越快，从库就落后越远。

说白了，就是干活的人太少。网络没问题，磁盘也没问题，瓶颈出在重放线程上。

二、并行复制的四代演进

MySQL 团队为了突破这个瓶颈，先后推出了四代方案，每一代都在前一代基础上改进。

第一代：基于Schema的并行（MySQL 5.6）

5.6 引入了最早的并行方案：如果两个事务操作的是不同数据库（schema），它们之间没有数据冲突，可以并行执行。

# my.cnf
slave_parallel_workers = 4
slave_parallel_type = DATABASE  # 基于数据库并行

局限性很大。现在的业务谁不是一个库搞到底？单库多表的场景下，这个方案基本等于没开。十个表都在同一个库里，全部串行。

实际项目中，一个业务库有40多张表，开启这个参数后延迟纹丝不动。

第二代：LOGICAL_CLOCK（MySQL 5.7.2）

这是真正意义上的突破。思路变了：不再看“是不是同一个库”，而是看“在主库是不是一起提交的”。

核心机制叫 Group Commit（组提交）。

什么是Group Commit？

MySQL 为了减少 fsync 次数，会把多个事务的 binlog 攒在一起写盘。比如同一时刻有事务 A、B、C 都在 commit，MySQL 会把它们放在一个组里，只做一次 fsync。

时间线：
t1: 事务A commit → 进入binlog cache
t2: 事务B commit → 进入binlog cache
t3: 事务C commit → 进入binlog cache
t4: 三个事务一起fsync到binlog文件（一次IO搞定）

组提交的关键：同一个组里的事务，在主库就是“同时”提交的，它们之间大概率不冲突。

5.7 在 binlog 里记录了每个事务的“逻辑时钟”（其实就是组提交的序列号）。从库看到两个事务的逻辑时钟相同，就知道它们在主库是同一组提交的，可以并行重放。

# my.cnf
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON

比 5.6 好在哪？不看数据库了，看主库实际的提交关系。单库多表也能并行。

但也容易踩坑：slave_preserve_commit_order 这个参数一定要开。不开的话，从库事务的提交顺序可能跟主库不一致，某些依赖提交顺序的业务逻辑会出问题。开了会损失一些并行度，但数据安全更重要。

第三代：WRITESET（MySQL 5.7.22）

LOGICAL_CLOCK 的问题在哪？粒度还是太粗。同一个组里的事务数量有限，大部分时间从库的 worker 还是在等。

WRITESET 换了思路：不看“主库什么时候提交”，而是看“两个事务操作的数据有没有重叠”。

事务A写了行 {id=1, id=2}
事务B写了行 {id=3, id=4}
→ A和B的写集合（WRITESET）不相交 → 可以并行！

即使事务 A 和事务 B 在主库不是同一个组提交的，只要它们操作的数据不重叠，从库也可以并行执行。

# my.cnf
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
binlog_transaction_dependency_tracking = WRITESET
transaction_write_set_extraction = XXHASH64
slave_preserve_commit_order = ON

并行度比 LOGICAL_CLOCK 高很多，但也带来了新问题——同一 session 的事务乱序风险，后面展开讲。

第四代：WRITESET_SESSION（MySQL 8.0.27）

WRITESET 的隐患：同一 session 里的两个事务，如果操作不同行，WRITESET 会认为它们不冲突、可以并行。但实际上同一个 session 的事务是有先后顺序的，乱序可能出问题。

8.0.27 加入了 WRITESET_SESSION：在 WRITESET 的基础上，保证同一 session 的事务串行执行，不同 session 的事务仍然可以按写集合判断并行。

# my.cnf推荐配置（8.0.27）
binlog_transaction_dependency_tracking = WRITESET_SESSION
transaction_write_set_extraction = XXHASH64
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON

8.0.27 的环境，直接用这个就对了。

三、版本选型对照表

不管哪个版本，slave_preserve_commit_order 都建议开启。

四、并行度怎么设？不是越大越好

slave_parallel_workers 设多少合适？很多人初期会想“越多越好”，直接设到32。结果从库 CPU 飙到100%，锁争用严重，延迟反而更大。

经验推荐值：

调优步骤：

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

-- 查看worker状态
SELECT 
  worker_id,
  thread_id,
  service_state,
  last_error_number,
  last_error_message
FROM performance_schema.replication_applier_status_by_worker;

五、延迟排查路径：四种现象四种打法

并行复制配好了，延迟还是高？下面四种场景需要逐一排查。

场景一：延迟持续增长，越来越大

十个延迟问题里有八个是这种。排查路径：

-- 第一步：看从库在干什么
SHOW PROCESSLIST;

-- 第二步：看有没有大事务阻塞
SELECT * FROM information_schema.innodb_trx
WHERE trx_started < NOW() - INTERVAL 30 SECOND
ORDER BY trx_started;

-- 第三步：看从库锁等待
SELECT * FROM performance_schema.data_lock_waits;

常见原因：

• 主库有大事务（DELETE几百万行、ALTER大表）
• 从库IO慢，relay log写入跟不上
• 并行复制没开或者配错了

解法：大事务拆小批量执行，IO慢就换SSD，并行复制参数按上面配。

场景二：延迟抖动，一阵一阵的

延迟不是持续增长，而是每隔几分钟飙一次，然后又慢慢降下来。

排查方向：

• 定时任务（每5分钟的批量写入）
• 监控/备份脚本（mysqldump、xtrabackup跑的时候IO飙升）
• 主库的checkpoint

这种场景通常是业务层的写入不均匀导致的。

场景三：Seconds_Behind_Master=0，但业务读到老数据

这个最坑。监控看着一切正常，延迟为0，但业务就是查不到新数据。

-- 用performance_schema看真实延迟
SELECT * FROM performance_schema.replication_applier_status;

-- 或者用心跳表对比
-- 主库写入当前时间
UPDATE heartbeat SET ts = NOW(6) WHERE id = 1;
-- 从库读取对比
SELECT TIMESTAMPDIFF(SECOND, ts, NOW(6)) AS real_lag FROM heartbeat WHERE id = 1;

Seconds_Behind_Master 是基于 binlog 里 TIMESTAMP 字段计算的，当某些事务不包含时间戳信息时，这个指标会显示0，但实际延迟可能存在。

解法就是上心跳表做业务级监控，比 Seconds_Behind_Master 靠谱得多。

场景四：延迟突然归零又涨上去

通常是某个大事务执行完了，SQL 线程瞬间追上，然后下一个大事务又开始堆积。

看 relay log 空间能辅助判断：

SHOW SLAVE STATUS\G
-- 看 Relay_Log_Space 字段
-- 如果一直在涨，说明IO线程拉的比SQL线程放的快

六、业务层调优：光调数据库参数不够

并行复制能解决 SQL 线程串行的瓶颈，但有些问题光靠参数搞不定。

拆大事务

大事务是延迟的头号杀手。

-- 错误写法：一次删100万行
DELETE FROM logs WHERE created_at < '2024-01-01';

-- 正确写法：分批删除
DELETE FROM logs WHERE created_at < '2024-01-01' LIMIT 10000;
-- 应用层循环执行，每批之间sleep(1)

一个典型例子：开发同学写了个定时清理任务，每月删3000万行日志，一个 DELETE 搞定。跑了两个月才发现从库延迟经常飙到1小时。改成每批5000行、间隔0.5秒之后，延迟从没超过10秒。

大表DDL用工具

-- 错误写法：直接ALTER
ALTER TABLE big_table ADD COLUMN x INT;

-- 正确写法：用gh-ost或pt-online-schema-change
-- gh-ost不会长时间锁表，对复制友好

读写分离要注意“读后写”

开了读写分离之后，如果业务逻辑是“先 SELECT 再 UPDATE”，SELECT 走从库可能读到老数据，UPDATE 走主库写了新数据，中间就出问题了。

要么在代码里强制这类查询走主库，要么用中间件（ProxySQL）配置规则把这类 SQL 路由到主库。

七、监控方案：光看一个指标不够

复制状态监控

-- 最基础：SHOW SLAVE STATUS
SHOW SLAVE STATUS\G
-- 关注：Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master

-- 更准确：performance_schema
SELECT * FROM performance_schema.replication_connection_status\G
SELECT * FROM performance_schema.replication_applier_status\G

业务延迟监控——心跳表方案

-- 在monitor库建心跳表
CREATE TABLE heartbeat (
  id INT PRIMARY KEY,
  ts TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6)
);
INSERT INTO heartbeat (id) VALUES (1);

后台任务每秒在主库 UPDATE 心跳表的 ts 字段，然后对比主从 ts 差值。这个差值就是真实延迟，比 Seconds_Behind_Master 准确，不依赖 binlog 里的时间戳。

八、升级5.7到8.0的并行复制变化

如果环境在做 5.7→8.0 升级，并行复制方面有几个点要注意：

升级后的推荐配置：

# 8.0.27 推荐
binlog_transaction_dependency_tracking = WRITESET_SESSION
transaction_write_set_extraction = XXHASH64
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON
innodb_redo_log_capacity = 4294967296  # 4GB，单位字节

九、面试怎么答

面试官：MySQL并行复制经历了哪几个阶段？各自原理是什么？

并行复制经历了四个阶段。5.6是基于Schema的并行，不同数据库的事务可以同时执行，但单库场景没用。5.7.2引入LOGICAL_CLOCK，利用主库的Group Commit机制，同组提交的事务可以在从库并行重放。5.7.22进一步引入WRITESET，通过分析事务的写集合判断是否冲突，不冲突就并行，粒度更细。8.0.27加了WRITESET_SESSION，在WRITESET基础上保证同一session事务串行，避免乱序问题。生产里建议8.0.27直接用WRITESET_SESSION。

面试官：slave_preserve_commit_order为什么建议开启？

并行重放后，从库事务的提交顺序可能跟主库不一致。如果业务逻辑依赖提交顺序（比如先插入后更新的时序），不开启可能导致数据不一致。开启后会损失一部分并行度，但换来的是数据安全性。生产环境建议始终开启。

面试官：Seconds_Behind_Master为0但业务读到老数据，怎么排查？

Seconds_Behind_Master 基于 binlog 中的 TIMESTAMP 字段计算，当事务不包含时间戳时会显示0。先用 performance_schema 的 replication_applier_status 查真实状态，再上心跳表做业务级监控——主库每秒写入当前时间到心跳表，从库读取对比差值，这个差值就是真实延迟。

避坑清单

总结

并行复制不是“改个参数就完事”的事。四代演进下来，每一代解决了不同层面的问题：

• 5.6 Schema并行 → 解决“完全没有并行”
• 5.7 LOGICAL_CLOCK → 利用组提交实现真正的并行
• 5.7.22 WRITESET → 通过写集合分析，粒度更细
• 8.0.27 WRITESET_SESSION → 兼顾并行度和session顺序

但并行复制只解决 SQL 线程的瓶颈。真正要做到延迟可控，还得在业务层把大事务拆掉、定时任务分批跑、读写分离路由做对。

并行复制解决“干活的人少”的问题，业务优化解决“活太大”的问题。两个都搞定，从库追不上主库的问题基本就治好了。