slave_parallel_workers 有效需满足：slave_parallel_type=logical_clock、主库binlog_transaction_dependency_tracking=writeset、binlog_format=row；建议从4起调，勿超cpu核心数。
slave_parallel_workers 设为多少才有效
MySQL 5.7+ 支持并行复制，但 slave_parallel_workers 不是设得越高越好。它只在启用基于逻辑时钟（MTS）的并行模式下起作用，而默认的 slave_parallel_type = DATABASE 实际上按库分发事务，如果主库只有单个库在写，那无论设成 8 还是 16，从库始终只用 1 个线程干活。
- 必须先确认
slave_parallel_type = LOGICAL_CLOCK（推荐），否则slave_parallel_workers > 0形同虚设 - 主库需开启
binlog_transaction_dependency_tracking = WRITESET（MySQL 8.0.19+ 默认），才能生成更细粒度的依赖信息，提升并行度 - 从库的
slave_parallel_workers建议从 4 开始试，超过 CPU 核心数后吞吐通常不再上升，反而因线程争抢引入延迟
例如：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';<br>SET GLOBAL slave_parallel_workers = 4;
为什么开了并行还是串行执行
常见现象：SHOW PROCESSLIST 里只看到一个 Slave_SQL_Running_State: Reading event from the relay log，其余 worker 线程长期处于 Waiting for an event from Coordinator。
- 最可能原因是 relay log 中事务缺乏并发调度依据：主库没开
binlog_transaction_dependency_tracking，或用了老版本 MySQL（ - 另一个隐藏条件：主库必须使用
ROW格式 binlog（binlog_format = ROW），STATEMENT或MIXED下 write-set 无法生成 - 检查从库是否启用了
slave_preserve_commit_order = ON（5.7.22+ 默认 OFF），设为 ON 会强制提交顺序，抵消并行效果
快速验证：
SELECT @@binlog_transaction_dependency_tracking, @@binlog_format;<br>SHOW SLAVE STATUS\G | grep -E "(Parallel|Dependency)";
调高 slave_parallel_workers 后同步反而更慢
这不是错觉。当 worker 数量超过实际可并行事务数时，协调线程（Coordinator）要花更多时间做分发、等待和冲突检测，尤其在写入热点表、大量主键冲突或频繁 DDL 的场景下。
- 单表高频更新（如订单流水表）会导致 write-set 冲突率飙升，worker 频繁回退重试，CPU 花在锁竞争上而非执行
- 如果主库有长事务（> 30s），它会阻塞后续所有事务的并行调度，整个 pipeline 堵死
- 从库磁盘 I/O 或 relay log 存储路径较慢（比如 NFS 或机械盘），worker 多了反而加剧 IO 争抢
建议动作：
• 查看 Seconds_Behind_Master 波动是否伴随 Retrieved_Gtid_Set 和 Executed_Gtid_Set 差距拉大
• 监控 SHOW STATUS LIKE 'Slave%' 中 Slave_open_temp_tables、Slave_retried_transactions 是否异常升高
• 临时降回 slave_parallel_workers = 2 对比延迟变化
还有哪些参数必须配套调整
slave_parallel_workers 不是孤立参数，几个关键兄弟值不匹配会直接废掉并行能力：
-
slave_pending_jobs_size_max（默认 128MB）：worker 队列内存上限。并发高时容易触发“Waiting for Slave Worker to free pending events”，需按slave_parallel_workers × 32MB估算上调 -
slave_checkpoint_period（默认 300ms）：检查点频率。太高（如 5000）会导致 crash 后恢复慢；太低（如 10）增加刷盘压力，建议 300–1000 -
relay_log_recovery = ON必须开启，否则重启后并行元数据丢失，降级为单线程 - MySQL 8.0.26+ 可考虑启用
slave_parallel_threads = AUTO（实验性），但生产环境仍建议固定值便于监控
典型组合：
SET GLOBAL slave_pending_jobs_size_max = 512*1024*1024;<br>SET GLOBAL slave_checkpoint_period = 500;
真正卡住同步速度的，往往不是 worker 数不够，而是主库没给从库留出并行机会——write-set 关闭、binlog_format 是 STATEMENT、或者单库单表扛下全部写流量。调参前先看主库配置和业务写入模式，比盲目加 worker 更管用。
