slave_parallel_workers应根据主库每秒事务组数设置：3–5组配4，超10组再调至8或12，勿超16；须确保slave_parallel_type=LOGICAL_CLOCK、binlog_format=ROW、组提交正常启用。
slave_parallel_workers设多少才不浪费也不卡顿
设太高会触发频繁线程切换，设太低又压不住主库的事务组吞吐。关键不是看CPU核数，而是看主库实际每秒能打出多少个可并行的事务组。
实操建议：
- 先在主库执行
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit%'，重点看Binlog_group_commit_trigger_count和Binlog_group_commit_trigger_timeout的每秒增量 - 如果每秒平均只有 3–5 组，
slave_parallel_workers=4就够了；超过 10 组再考虑调到 8 或 12 - 别跨过 16：MySQL 8.0 对 >16 个 worker 的调度优化有限，反而容易因锁竞争拖慢 SQL 线程
- 动态生效必须配
STOP SLAVE; SET GLOBAL slave_parallel_workers = N; START SLAVE;，只改变量不重启复制无效
为什么设了slave_parallel_workers还是单线程跑
最常见原因是没打开并行开关，或者主库根本没产生可并行的事务组。MySQL 不会因为开了 worker 就自动并行——它得有“组”才能分发。
检查步骤：
- 确认从库
slave_parallel_type是'LOGICAL_CLOCK'（不是默认的'DATABASE'） - 确认主库
binlog_format=ROW且binlog_order_commits=OFF（这是组提交前提） - 确认主库
sync_binlog=1和innodb_flush_log_at_trx_commit=1同时开启，否则组提交节奏被打乱 - 执行
SHOW PROCESSLIST，看到多个Slave_worker线程处于Waiting for an event from Coordinator才算真并行；如果全是Waiting for preceding transaction to commit，说明事务逻辑串行化太重，不是 worker 数的问题
MySQL 8.0必须配WRITESET才能真正提速吗
不是必须，但强烈推荐。WRITESET 是 MySQL 8.0.22+ 才真正可用的并行增强模式，它让并行判断粒度从“事务提交时间”细化到“影响的行集合”，大幅提高单库单表场景下的并行率。
但要注意：
- WRITESET 要求主库设
binlog_transaction_dependency_tracking=WRITESET，低于 8.0.22 只能用WRITESET_SESSION，效果打折扣 - 从库仍要设
slave_parallel_type='LOGICAL_CLOCK'（不是'WRITESET'），这个值目前不合法 -
slave_preserve_commit_order=ON必须开，否则可能丢一致性；关掉它，slave_parallel_workers再多也白搭 - WRITESET 对主库 CPU 有额外开销（计算 writeset hash），高并发写入下需观察
Cpu_usage是否明显上升
哪些参数和slave_parallel_workers冲突会拖慢复制
几个典型翻车点：盲目调大 innodb_buffer_pool_size 导致 swap、关掉 innodb_flush_log_at_trx_commit 引发锁等待雪崩、设错 innodb_io_capacity 让 IO 调度器误判。
尤其注意：
-
innodb_log_file_size设太大（如 >4GB）会导致 crash recovery 时间陡增，间接拉长复制启动耗时 -
sync_binlog和innodb_flush_log_at_trx_commit必须同为 1，设成 0 或 2 虽然写入快，但主库宕机就丢 binlog 或 redo，复制直接断裂 -
innodb_io_capacity和innodb_io_capacity_max要贴合磁盘真实 IOPS：SSD 可设 2000/4000，机械盘别超 200/400 - 从库禁用
SELECT ... FOR UPDATE和无索引的SELECT COUNT(*)，这类操作会抢占资源，让 worker 线程等锁等扫描，比 worker 数少更致命
slave_parallel_workers 就只是个摆设数字。 
