MySQL 5.7的并行复制是为了解决传统单线程复制导致的从库延迟问题而推出的功能，默认情况下会根据事务的提交顺序和依赖关系调度并行回放，但在单库场景中，很多用户会发现即使开启了并行复制，延迟依然没有明显降低，这时候调整从库调度算法为LOGICAL_CLOCK往往能带来改善。
单库下并行复制效果不佳的原因
MySQL 5.7并行复制默认的调度算法是DATABASE，这个算法的核心逻辑是按照不同的数据库来分配并行回放的任务，只有当多个事务属于不同的数据库时，才会被调度为并行执行。在单库场景下，所有的事务都属于同一个数据库，DATABASE算法会认为这些事务存在依赖关系，只能串行回放，因此并行复制完全无法发挥作用，复制效率和单线程复制没有区别。
除了调度算法的问题，单库场景下还存在事务依赖的判定问题。默认情况下，MySQL会认为同一数据库内的事务可能存在数据冲突，为了保证数据一致性，不会贸然并行回放，这也是单库下并行复制失效的重要原因。
LOGICAL_CLOCK调度算法的原理
LOGICAL_CLOCK是MySQL 5.7引入的另一种并行复制调度算法，它的核心是通过逻辑时钟来判断事务之间的依赖关系，而不是单纯依赖数据库归属。每个事务在提交时会被分配一个逻辑时钟值，只要两个事务的逻辑时钟值没有重叠的依赖区间，就可以被判定为可以并行回放的事务。
在单库场景下，很多事务其实并不存在实际的数据冲突，比如操作不同表、操作同一表的不同行的事务，它们之间的逻辑时钟依赖区间可能没有重叠，LOGICAL_CLOCK算法就可以把这些事务调度为并行回放，从而提升从库的复制效率。
如何配置从库调度算法为LOGICAL_CLOCK
配置过程只需要在从库执行相关参数设置即可，不需要修改主库配置，具体步骤如下：
1. 停止从库复制线程
在调整参数前，需要先停止从库的SQL回放线程，避免配置过程中出现数据不一致的问题，执行以下命令：
STOP SLAVE SQL_THREAD;
2. 设置调度算法参数
修改从库的并行复制调度算法为LOGICAL_CLOCK，同时设置合适的并行工作线程数，执行以下命令：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; -- 设置并行工作线程数，一般建议设置为CPU核心数的2-4倍，这里以8为例 SET GLOBAL slave_parallel_workers = 8; -- 开启事务依赖跟踪，保证并行回放的数据一致性 SET GLOBAL slave_preserve_commit_order = ON;
3. 重启从库复制线程
参数设置完成后，重新启动从库的SQL回放线程，让配置生效：
START SLAVE SQL_THREAD;
4. 持久化配置
为了让配置在从库重启后依然生效，需要把参数写入从库的配置文件my.cnf中：
[mysqld] slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 8 slave_preserve_commit_order = ON
配置后的效果验证
配置完成后，可以通过以下方式验证并行复制是否生效：
- 查看从库的状态，观察
Slave_parallel_workers的值是否为设置的8，Slave_parallel_type是否为LOGICAL_CLOCK - 查看从库的复制延迟，对比配置前后的
Seconds_Behind_Master数值，单库场景下延迟一般会有明显下降 - 查看并行回放的统计信息，执行
SHOW STATUS LIKE 'Slave_parallel%';可以看到并行回放的事务数量相关指标
注意事项
虽然LOGICAL_CLOCK可以提升单库下的并行复制效率，但也不是所有场景都适用：
- 如果单库中的事务大部分都存在数据冲突，比如大量更新同一行的事务，那么即使使用LOGICAL_CLOCK，并行度也不会很高
- 开启
slave_preserve_commit_order参数可以保证事务在从库的提交顺序和主库一致，但会稍微增加一些调度开销，如果对提交顺序没有严格要求，可以根据实际情况调整 - 并行工作线程数不是越多越好，过多的线程会增加上下文切换的开销，反而可能降低复制效率，需要根据从库的CPU配置合理设置
需要注意，LOGICAL_CLOCK算法是MySQL 5.7的原生功能，不需要额外安装插件，只要版本符合要求就可以直接配置使用。
MySQL_5.7并行复制单库LOGICAL_CLOCK从库调度算法修改时间：2026-06-17 03:12:30