MySQL 并行复制（Parallel Replication）是为了解决传统 MySQL 主从复制中 "主库并行写，从库串行读" 导致的同步延迟问题而引入的机制。
在早期的 MySQL 版本中，从库（Slave）只有一个 SQL 线程负责重放中继日志（Relay Log），当主库（Master）并发写入压力较大时，从库的单线程无法跟上主库的速度，从而产生严重的 主从延迟（Seconds_Behind_Master）。
MySQL 并行复制的演进经历了三个主要阶段：库级别并行（5.6）、组提交/逻辑时钟（5.7） 和 WriteSet（8.0）。以下是详细的原理描述：
- 总体架构模型
无论哪个版本，并行复制的底层线程模型基本一致，即 MTS（Multi-Threaded Slave）：
Coordinator（协调者线程）： 也就是原来的 SQL 线程。它不再直接执行 SQL，而是负责读取 Relay Log，判断事务是否可以并行执行，并将其分发给 Worker 线程。
Workers（工作线程）： 多个线程，负责具体的 SQL 执行（Apply Log）。
- MySQL 5.6：基于 Schema（库）级别的并行复制
这是 MySQL 最早引入的并行复制机制。
原理：
Coordinator 线程根据事务涉及的 数据库名（Schema Name） 进行分发。
如果事务 A 操作 DB1，事务 B 操作 DB2，它们会被分发给不同的 Worker 线程并行执行。
如果事务 A 和事务 B 都操作 DB1，它们必须串行执行。
局限性：
这种策略要求业务场景必须是多库架构。然而，大多数业务是"单库多表"甚至"单库单表"的热点架构。在这种情况下，所有事务都指向同一个库，导致并行退化为串行，性能提升微乎其微。
- MySQL 5.7：基于 Logical Clock（逻辑时钟）的并行复制
这是目前应用最广泛的并行复制方式，真正实现了"行级"并发的潜力。
核心思想（基于组提交 Group Commit）：
"如果在主库上能够同时提交的事务，那么它们在从库上也一定可以并行执行。"
因为如果事务之间存在锁冲突，它们在主库上就不可能进入同一个提交阶段。
实现原理：
MySQL 在 Binlog 中引入了两个核心标记（通过 GTID_EVENT 或 ANONYMOUS_GTID_EVENT 记录）：
sequence_number：全局递增的事务序列号。
last_committed：该事务提交时，上一个已提交事务的 sequence_number。
判断逻辑：
从库的 Coordinator 在分发事务时，会检查当前这批事务的 last_committed。
如果多个事务的 last_committed 相同（或者在同一个区间内），说明它们是在主库的同一个"时间窗口"内完成 Prepare 阶段的，意味着它们之间没有锁冲突。
这些事务就可以被分发给不同的 Worker 并行回放。
配置参数：
sql
复制
slave_parallel_type = LOGICAL_CLOCK
- MySQL 8.0：基于 WriteSet（写集合）的并行复制
MySQL 5.7 的逻辑时钟依赖于主库的并发度。如果主库本身写入压力不大，或者主库是单线程批量写入，从库也就无法并行。MySQL 8.0 引入了 WriteSet 解决了这个问题。
原理：
主库在生成 Binlog 时，会计算事务修改行数据的哈希值（WriteSet）。它不再单纯依赖"是否同时提交"，而是依赖 "是否修改了同一行数据"。
机制：
MySQL 会追踪事务涉及的每一行主键或唯一键的 Hash 值。
如果事务 A 修改了 ID=1 的行，事务 B 修改了 ID=2 的行，即使它们在主库是先后提交的（时间上不重叠），MySQL 也会判断它们没有依赖关系（last_committed 可能会被标记为相同）。
这样，从库就可以并行执行这两个事务。
优势：
即使主库是串行写入，只要操作的数据行不冲突，从库依然可以并行回放，极大地提高了从库的吞吐量。
配置参数：
sql
复制
binlog_transaction_dependency_tracking = WRITESET
- 关键配置与注意事项
为了确保并行复制的数据一致性和性能，通常涉及以下关键参数：
slave_parallel_workers：
设置 Worker 线程的数量。通常设置为 CPU 核心数的 1-2 倍（例如 4~8 个），过高会导致线程上下文切换开销。
slave_preserve_commit_order：
重要性： 在并行执行时，Worker 线程完成事务的顺序可能与主库不同（比如小事务先执行完）。
开启此参数（ON）后，Coordinator 会等待前面的事务提交后，才允许后面的事务提交。这保证了从库上事务的 提交顺序 与主库严格一致，防止出现数据回读时的逻辑混乱。
MySQL 并行复制通过将原来的单线程串行回放改造为多线程并行回放，利用主库的事务依赖关系（锁冲突或数据行冲突）来决定分发策略，有效地解决了主从同步延迟问题。