SQL slave_parallel_workers 的并行复制线程数经验值

slave_parallel_workers应根据slave_parallel_type模式合理设置：database模式下设为活跃库数的整数倍，logical_clock模式下推荐4–8；需同步调大slave_pending_jobs_size_max，确保binlog_format=row，并关注i/o与锁竞争。

slave_parallel_workers 设多少才不拖慢主库又跑得动从库

设成 0 就退化为单线程复制，设太高反而抢主库资源、触发锁争用、甚至让从库 relay log 写入变慢。经验值不是固定数字，而是跟 slave_parallel_type 模式强绑定——你用的是 DATABASE 还是 LOGICAL_CLOCK，直接决定线程数有没有意义。

• 如果 slave_parallel_type = DATABASE（mysql 5.6/5.7 默认），slave_parallel_workers 只能设成「库数量」的整数倍，且不能超过实际活跃库数；设成 8 却只有 2 个库在写，剩下 6 个线程永远空转+占内存
• 如果 slave_parallel_type = LOGICAL_CLOCK（推荐，5.7.19+ / 8.0），线程数才有真实并发效果，但上限受 binlog_group_commit_sync_delay 和主库事务提交节奏制约；通常 4–8 是安全起点，超 16 很少带来收益，反而增加调度开销
• 必须同时调大 slave_pending_jobs_size_max（默认 128MB），否则并行队列满了就卡住，看着线程在跑，实际复制延迟飙升

为什么设了 16 个线程，show processlist 里却只看到 3 个 Worker 线程在干活

这不是配置没生效，是 MySQL 的懒启动机制：Worker 线程只在真正有并行任务时创建，空闲超 60 秒自动销毁。所以 show processlist 看到的活跃 Worker 数是瞬时值，不代表配置无效。

• 查真实启用数看 SHOW STATUS LIKE 'Slave_workers%'，重点关注 Slave_workers（总配置数）和 Slave_retried_transactions（重试次数高说明并行冲突多）
• 如果 Seconds_Behind_Master 波动剧烈（忽快忽慢），大概率是 slave_preserve_commit_order = ON 被触发，强制串行化部分事务，此时加线程没用
• 注意 innodb_thread_concurrency 如果设得太低（比如 0 或 8），会反向限制 Worker 线程获取 InnoDB 资源的能力，形成隐性瓶颈

升级到 MySQL 8.0 后并行复制反而更慢了？

8.0 默认启用了 slave_preserve_commit_order = ON，且 slave_parallel_type 强制为 LOGICAL_CLOCK，这本是好事，但如果你主库 binlog 格式还是 MIXED 或 STATEMENT，会导致大量事务无法并行分组——因为这些格式下事务间依赖关系不可靠，MySQL 宁可保守串行。

• 必须确认主库 binlog_format = ROW，否则并行能力直接打五折
• 检查从库 Error log 里有没有 Cannot schedule transaction because of commit order violation，这是典型信号
• 8.0.22+ 新增 slave_parallel_workers_auto_adjust（默认 OFF），开启后会根据负载动态调线程数，但线上建议保持 OFF，手动控制更稳

监控并行复制健康度不能只盯 Seconds_Behind_Master

这个值掩盖太多细节：可能 IO 线程早追上了，SQL 线程却卡在某个大事务上；也可能所有 Worker 都在等同一把 MDL 锁，延迟涨得飞快但 show slave status 看不出端倪。

• 关键指标组合查：Slave_SQL_Running_State（是否卡在 “Waiting for preceding transaction to commit”）、Retrieved_Gtid_Set 和 Executed_Gtid_Set 差值（反映 relay log 积压量）
• 定期执行 select * FROM performance_schema.replication_applier_status_by_worker，看每个 Worker 的 LAST_SEEN_TRANSACTION 和 WORKING_NUMBER 是否均匀分布
• 最易忽略的一点：磁盘 I/O。并行复制会显著增加 relay log 的随机写压力，如果从库用的是机械盘或 IOPS 限速的云盘，slave_parallel_workers > 4 反而让整体吞吐下降

线程数调参本质是平衡——主库压力、从库 I/O、事务依赖粒度、锁竞争强度，四者牵一发而动全身。别迷信“别人用 8 个很稳”，先看自己主库每秒多少事务、平均事务大小、有没有大表 DDL，再动手改 slave_parallel_workers。