MySQL Replication如何实现并行复制？
传统单线程复制说明众所周知，MySQL在5.6版本之前，主从复制的从节点上有两个线程，分别是I/O线程和SQL线程。I/O线程负责接收二进制日志的Event写入RelayLog。SQL线程读取RelayLog并在数据库中进行回放。以上方式偶尔会造成延迟，那么可能造成主从节点延迟的情况有哪些?1.主库执行大事务（如：大表结构变更操作）。2.主库大批量变更（如：大量插入、更新、删除操作）。3.ROW同步模式下，主库大表无主键频繁更新。4.数据库参数配置不合理，从节点性能存在瓶颈（如：从节点事务日志设置过小，导
传统单线程复制说明
众所周知，MySQL在5.6版本之前，主从复制的从节点上有两个线程，分别是I/O线程和SQL线程。
I/O线程负责接收二进制日志的Event写入Relay Log。
SQL线程读取Relay Log并在数据库中进行回放。
以上方式偶尔会造成延迟，那么可能造成主从节点延迟的情况有哪些?
1.主库执行大事务（如：大表结构变更操作）。
2.主库大批量变更（如：大量插入、更新、删除操作）。
3.ROW同步模式下，主库大表无主键频繁更新。
4.数据库参数配置不合理，从节点性能存在瓶颈（如：从节点事务日志设置过小，导致频繁刷盘）。
5.网络环境不稳定，从节点IO线程读取binlog存在延迟、重连情况。
6.主从硬件配置差异，从节点的硬件资源使用达到上限。(比如：主节点SSD盘，从节点SAS盘)
可以对以上延迟原因做个大致分类。
1.硬件方面问题（包括磁盘IO、网络IO等）
2.配置方面问题。
3.数据库设计问题。
4.主库大批量变更，从节点SQL单线程处理不够及时。
总结
分析以上原因可以看出要想降低主从延迟，除了改善硬件方面条件之外，另外就是需要DBA关注数据库设计和配置问题，最后就是需要提高从节点的并发处理能力，由单线程回放改为多线程并行回放是一个比较好的方法，关键点在于如何在多线程恢复的前提下解决数据冲突和故障恢复位置点的确认问题。
MySQL5.6基于库级别的并行复制
在实例中有多个数据库的情况下，可以开启多个线程，每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类
Coordinator和WorkThread。
线程分工执行逻辑
Coordinator线程负责判断事务是否可以并行执行，如果可以并行就把事务分发给WorkThread线程执行，如果判断不能执行，如DDL，跨库操作等，就等待所有的worker线程执行完成之后，再由Coordinator执行。
关键配置信息
slave-parallel-type=DATABASE
方案不足点
这种并行复制的模式,只有在实例中有多个DB且DB的事务都相对繁忙的情况下才会有较高的并行度，但是日常维护中其实单个实例的的事务处理相对集中在一个DB上。通过观察延迟可以发现基本上都是基于热点表出现延迟的情况占大多数。如果能够提供基于表的并行度是一个很好方法。
MySQL5.7基于组提交的并行复制
组提交说明
简单来说就是在双1的设置下，事务提交后即刷盘的操作改为多个事务合并成一组事务再进行统一刷盘，这样处理就降低了磁盘IO的压力。详细资料参考
老叶茶馆关于组提交的说明推文https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg
一组事务同时提交也就意味着组内事务不存在冲突，故组内的事务在从节点上就可以并发执行，问题在于如何区分事务是否在同一组中的，于是在binlog中出现了两个新的参数信息last_committed 和 sequence_number
如何判断事务在一个组内呢?
解析binlog可以发现里面多了
last_committed和sequence_number两个参数信息，其中last_committed存在重复的情况。
sequence_number# 这个值指的是事务提交的序号，单调递增。last_committed# 这个值有两层含义，1.相同值代表这些事务是在同一个组内，2.该值同时又是代表上一组事务的最大编号。
[root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committed GTID last_committed=0 sequence_number=1 GTID last_committed=0 sequence_number=2 GTID last_committed=2 sequence_number=3 GTID last_committed=2 sequence_number=4 GTID last_committed=2 sequence_number=5 GTID last_committed=2 sequence_number=6 GTID last_committed=6 sequence_number=7 GTID last_committed=6 sequence_number=8
数据库配置
slave-parallel-type=LOGICAL_CLOCK
方案不足点
基于组提交的同步有个不足点，就是当主节点的事务繁忙度较低的时候，导致时间段内组提交fsync刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组里面只有一个事务，这样从节点的多线程就基本用不到，可以通过设置下面两个参数，让主节点延迟提交。
binlog_group_commit_sync_delay # 等待延迟提交的时间，binlog提交后等待一段时间再 fsync。让每个 group 的事务更多，人为提高并行度。
binlog_group_commit_sync_no_delay_count # 待提交的最大事务数，如果等待时间没到，而事务数达到了，就立即 fsync。达到期望的并行度后立即提交，尽量缩小等待延迟。
MySQL8.0基于writeset的并行复制
writeset 基于事务结果冲突进行判断事务是否可以进行并行回放的方法，他由
binlog-transaction-dependency-tracking参数进行控制，默认采用WRITESET方法。
关键参数查看
| Command-Line Format | --binlog-transaction-dependency-tracking=value |
|---|---|
| System Variable | binlog_transaction_dependency_tracking |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | COMMIT_ORDER |
| Valid Values | COMMIT_ORDER WRITESET WRITESET_SESSION |
参数配置项说明
COMMIT_ORDER# 使用 5.7 Group commit 的方式决定事务依赖。WRITESET# 使用写集合的方式决定事务依赖。WRITESET_SESSION# 使用写集合，但是同一个session中的事务不会有相同的last_committed。
writeset 是一个HASH类型的数组，里面记录着事务的更新信息，通过
transaction_write_set_extraction判断当前事务更新的记录与历史事务更新的记录是否存在冲突，判断过后再采取对应处理方法。writeset储存的最大存储值由binlog-transaction-dependency-history-size控制。
需要注意的是，当设置成
WRITESET或WRITESET_SESSION的时候，事务提交是无序状态的，可以通过设置slave_preserve_commit_order=1强制按顺序提交。
binlog_transaction_dependency_history_size
设置保存在内存中的行哈希数的上限，用于缓存之前事务修改的行信息。一旦达到这个哈希数，就会清除历史记录。
| Command-Line Format | --binlog-transaction-dependency-history-size=# |
|---|---|
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Integer |
| Default Value | 25000 |
| Minimum Value | 1 |
| Minimum Value | 1000000 |
transaction_write_set_extraction
该模式支持三种算法，默认采用XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。该参数已经在MySQL 8.0.26中被弃用，后续将会进行删除。
| Command-Line Format | --transaction-write-set-extraction[=value] |
|---|---|
| Deprecated | 8.0.26 |
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global, Session |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | XXHASH64 |
| Valid Values | OFF MURMUR32 XXHASH64 |
数据库配置
slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 8 binlog_transaction_dependency_tracking = WRITESET slave_preserve_commit_order = 1
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
