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。
