📌今日关键词：MySQL并行复制、主从延迟、LOGICAL_CLOCK、WRITESET、MTS调优

大家好，我是数据库小学妹 👋

之前我们聊过主从同步失败的五大诱因，有粉丝朋友问我："小学妹，我的从库倒没挂，但 Seconds_Behind_Master 一直飙到几千秒，延迟越来越大怎么办？"

这个问题我太有发言权了。虽然我们讲过主从延迟的5个常见原因和3个排查命令，但那只是入门级别。真正要解决"从库追不上"的问题，得搞懂并行复制这个核心机制。

我一开始以为并行复制就是改个参数的事，设个 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），它们之间没有数据冲突，可以并行执行。

```ini
# 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里记录了每个事务的"逻辑时钟"（其实就是组提交的序列号）。从库看到两个事务的逻辑时钟相同，就知道它们在主库是同一组提交的，可以并行重放。

```ini
# 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在主库不是同一个组提交的，只要它们操作的数据不重叠，从库也可以并行执行。

```ini
# 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高很多，但也带来了新问题，我们后面展开讲。

### 第四代：WRITESET_SESSION（MySQL 8.0.27+）

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

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

```ini
# 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+的环境，直接用这个就对了。

---

## 三、版本选型对照表

| MySQL版本 | 推荐方案 | 关键参数 |
| --- | --- | --- |
| 5.6 | Schema并行（聊胜于无） | slave_parallel_type=DATABASE |
| 5.7.2 ~ 5.7.21 | LOGICAL_CLOCK | slave_parallel_type=LOGICAL_CLOCK |
| 5.7.22 ~ 8.0.26 | WRITESET | binlog_transaction_dependency_tracking=WRITESET |
| 8.0.27+ | WRITESET_SESSION | binlog_transaction_dependency_tracking=WRITESET_SESSION |

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

---

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

slave_parallel_workers 设多少合适？我最初的想法是"越多越好"，直接设了32。结果从库CPU飙到100%，锁争用严重，延迟反而更大了。

经验值：

| 机器配置 | 建议worker数 |
| --- | --- |
| 4核8G | 4~8 |
| 8核16G | 8~16 |
| 16核32G | 16~32 |

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

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

---

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

并行复制配好了，延迟还是高？下面四种场景，我一个个讲。

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

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

```sql
-- 第一步：看从库在干什么
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，但业务就是查不到新数据。

```sql
-- 用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空间能辅助判断：

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

---

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

并行复制能解决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用工具

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

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

### 读写分离要注意"读后写"

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

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

---

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

### 复制状态监控

```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
```

### 业务延迟监控

心跳表方案：

```sql
-- 在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升级，并行复制方面有几个点要注意：

| 变化 | 说明 |
| --- | --- |
| WRITESET_SESSION | 8.0.27+新增，比WRITESET更安全，推荐开启 |
| 命令语法更新 | SHOW SLAVE STATUS → SHOW REPLICA STATUS（8.0.22+兼容老语法） |
| redo log格式变化 | 8.0 redo log格式有调整，升级后需重新调innodb_redo_log_capacity |
| 认证插件变更 | caching_sha2_password是8.0默认，从库连主库要确认密码插件兼容 |

升级后的推荐配置：

```ini
# 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查真实状态，再上心跳表做业务级监控——主库每秒写入当前时间到心跳表，从库读取对比差值，这个差值就是真实延迟。

---

## 避坑清单

| 序号 | 坑点 | 后果 | 正确做法 |
| --- | --- | --- | --- |
| 1 | 不开并行复制就指望延迟自己降 | 延迟随写入量线性增长 | 5.7+至少用LOGICAL_CLOCK |
| 2 | slave_parallel_workers设太大 | CPU飙高、锁争用严重 | 从8开始，观察后再调 |
| 3 | 不开slave_preserve_commit_order | 从库提交顺序错乱，数据不一致 | 生产环境必须ON |
| 4 | WRITESET模式下同一session事务冲突 | 从库数据错乱或报错 | 8.0.27+用WRITESET_SESSION |
| 5 | 只看Seconds_Behind_Master | 指标失真以为没延迟 | 上心跳表+performance_schema |
| 6 | 主库跑大事务不拆分 | 从库阻塞几十分钟 | 分批执行，每批LIMIT控制行数 |
| 7 | 大表直接ALTER不走工具 | 复制延迟飙升、锁表 | 用gh-ost或pt-osc |
| 8 | 读写分离不考虑"读后写" | 业务读到旧数据做错误写入 | 关键查询路由到主库 |
| 9 | 升级8.0后不调redo log参数 | redo log格式变化导致IO异常 | 升级后调innodb_redo_log_capacity |
| 10 | 以为调参数就能解决所有延迟 | 忽略业务层大事务、定时任务等根因 | 参数+业务双管齐下 |

---

## 总结

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

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

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

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

我是数据库小学妹，咱们下篇见 👋


📌今日关键词：MySQL并行复制、主从延迟、LOGICAL_CLOCK、WRITESET、MTS调优

MySQL从库延迟根因剖析：并行复制机制演进与生产调优实战

拆解MySQL并行复制的演进历程，从单线程瓶颈到Group Commit、LOGICAL_CLOCK、WRITESET、WRITESET_SESSION，配合延迟排查路径和调优实战，帮你解决从库追不上主库的问题

人工智能

MySQL主从复制延迟问题解析：深入剖析并行复制四代演进（5.6 Schema并行→5.7 LOGICAL_CLOCK→5.7.22 WRITESET→8.0.27 WRITESET_SESSION），详解参数配置、大事务拆分、业务层优化等实战解决方案，帮助DBA彻底解决从库追不上主库的难题。

数据安全

中间件

数据库

路由

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL从库延迟根因剖析：并行复制机制演进与生产调优实战-腾讯云开发者社区-腾讯云

MySQL从库延迟根因剖析：并行复制机制演进与生产调优实战

MySQL从库延迟根因剖析：并行复制机制演进与生产调优实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐