设为4～8是多数oltp场景合理起点，因worker数超主库实际事务组密度会增大coordinator开销、加剧线程切换、延长等待，甚至因长事务阻塞导致全部worker闲置；需结合performance_schema和系统监控验证真实负载。
因为MySQL 5.7的并行复制把单线程SQL回放改成了多worker并发执行，前提是正确启用LOGICAL_CLOCK模式——否则slave_parallel_workers设成16也只跑1个线程。
为什么slave_parallel_workers设了却没效果？
根本原因是默认slave_parallel_type = 'DATABASE'，这个模式只在跨多个库写入时才分发事务。如果所有表都在order_db里，哪怕你设了slave_parallel_workers = 8，实际只有1个worker干活，其余7个全程空闲。
- 检查当前模式：
SHOW VARIABLES LIKE 'slave_parallel_type';，返回DATABASE就踩坑了 - 确认业务是否单库：
SELECT COUNT(DISTINCT table_schema) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys');，结果为1就别指望DATABASE模式 -
slave_parallel_workers = 0是纯单线程；= 1反而比0还慢约20%，因多一层协调开销；必须> 1且slave_parallel_type = 'LOGICAL_CLOCK'才真正启用并行
LOGICAL_CLOCK模式依赖主库组提交，不是光改从库参数就行
这个模式靠主库binlog里的last_committed和sequence_number字段来分组事务，但这些字段只在特定条件下生成：
- 主库
binlog_format必须是ROW——MIXED或STATEMENT下不记录组提交信息 - 主库需开启组提交：
binlog_group_commit_sync_delay > 0（如100）且binlog_group_commit_sync_no_delay_count >= 10 - 从库必须配
slave_preserve_commit_order = 1，否则事务提交顺序错乱，可能引发数据不一致 - 操作要停复制：
STOP SLAVE;→SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';→SET GLOBAL slave_parallel_workers = 4;→START SLAVE;
怎么验证并行复制真正在跑？
不能只看Seconds_Behind_Master = 0或Slave_SQL_Running_State，得查底层状态：
-
SHOW PROCESSLIST;里应看到多个system user线程，状态为Waiting for an event from Coordinator -
SELECT * FROM performance_schema.replication_applier_status_by_worker;，WORKER_ID应有多个非NULL的THREAD_ID -
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G;中WORKERS_PROCESSED值持续增长，说明coordinator正在分发任务
最容易被忽略的是DDL语句：它天然阻塞整个SQL线程，LOGICAL_CLOCK模式下也只能缓解，无法并行。遇到ALTER TABLE类延迟，得提前绕过重放，手动执行。
