设为4～8是多数OLTP场景合理起点，因worker数超主库实际事务组密度会增大Coordinator开销、加剧线程切换、延长等待，甚至因长事务阻塞导致全部worker闲置；需结合performance_schema和系统监控验证真实负载。
设为 4～8 是多数 OLTP 场景的合理起点，不是越多越好，超过实际可并行事务组数反而拖慢同步速度。
为什么不能盲目调高 slave_parallel_workers
这个参数控制 worker 线程数量，但真正能并发执行的事务组取决于主库 binlog 的 last_committed 分组密度。设得过高会带来明显副作用：
- Coordinator 线程分发开销增大，尤其在热点表或主键冲突多时，排队等待变长
- CPU 上下文切换频繁，线程调度抖动加剧，
Seconds_Behind_Master波动反而更大 - 实测显示：物理 CPU 核数为 8 的机器，设成 16 后吞吐未提升，但
SHOW PROCESSLIST中大量 Worker 线程卡在Waiting for an event from Coordinator - 长事务（>30s）会阻塞整个并行队列，后续事务无法推进
last_committed，worker 全部闲置
怎么判断当前值是否合适
别只盯着 Seconds_Behind_Master，它不反映 worker 实际负载。重点关注以下三点：
- 执行
SELECT * FROM performance_schema.replication_applier_status_by_worker\G，确认WORKER_ID行数等于你设的slave_parallel_workers值，且APPLYING_TRANSACTION字段有持续更新 - 运行
top -H -p $(pgrep mysqld)，观察各 worker 线程 CPU 占用是否均匀；如果只有 1–2 个跑满、其余长期0%，说明瓶颈不在并行度，而在磁盘 I/O 或 SQL 回放本身（比如大 UPDATE 缺索引） - 检查
Relay_Log_Space是否持续增长——若增长快但Exec_Master_Log_Pos推进慢，问题在 IO 线程或网络，调slave_parallel_workers没用
设置前必须满足的硬性前提
slave_parallel_workers > 1 仅是“油门”，没配对的“引擎”和“变速箱”，踩再狠也跑不快。以下三步缺一不可：
- 主库
binlog_format必须为ROW；MIXED或STATEMENT下LOGICAL_CLOCK机制基本失效 - 从库先执行
STOP SLAVE SQL_THREAD，再设SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'（顺序不能反，否则不生效） - 从库必须设
SET GLOBAL slave_preserve_commit_order = ON，否则并行回放可能破坏事务可见顺序，导致业务读到不一致状态
真正起效的 worker 数量，取决于主库组提交的实际节奏和从库 I/O+CPU 的真实瓶颈。上线后务必用 performance_schema 表和系统级监控交叉验证，而不是只改一个数字就以为万事大吉。
