并行复制效果取决于版本、slave_parallel_type策略及主库组提交质量，仅调slave_parallel_workers无效；mysql 5.6需多库才并行，5.7+须设logical_clock且主库需有效组提交，否则仍串行。
并行复制不是“开个参数就能降延迟”，它必须匹配你的业务写入模式，否则 slave_parallel_workers 设为 16 也和设为 0 没区别。
为什么改了 slave_parallel_workers 延迟没变？
这是最常踩的坑：只调线程数，不看并行策略是否生效。MySQL 并行复制能否真正并发，取决于你用的是哪个版本、启用了哪种 slave_parallel_type，以及主库 binlog 中事务是否满足并行条件。
- MySQL 5.6 默认是
slave_parallel_type=DATABASE，只对跨库事务并行——如果你所有表都在db_shop里，那所有事务仍走同一个 SQL 线程 - MySQL 5.7+ 必须显式设
slave_parallel_type=LOGICAL_CLOCK才能启用组提交并行；若漏掉这步，slave_parallel_workers再大也无效 - 主库未开启
binlog_group_commit_sync_delay或binlog_group_commit_sync_no_delay_count，会导致组提交效果弱，从库拿到的事务“时间戳”太散，可并行度下降
LOGICAL_CLOCK 模式下，哪些事务能真正并行？
它依赖主库的组提交（Group Commit）机制：同一 flush 阶段刷盘的事务，会被标记相同的逻辑时钟值（last_committed），从库据此分发到同一 worker 线程；不同 last_committed 值的事务才可能进不同线程。
- 查主库是否真有组提交：执行
SHOW MASTER STATUS后，再查SELECT @@global.binlog_group_commit_sync_delay—— 若为 0，说明组提交基本靠运气，建议设为 1000–10000（单位微秒） - 查从库并行效果：执行
SHOW PROCESSLIST，看是否有多个system user状态的线程在运行；再查SELECT * FROM performance_schema.replication_applier_status_by_worker，观察LAST_SEEN_TRANSACTION和WORKER_ID分布是否分散 - 注意陷阱：即使
last_committed不同，若两个事务更新同一行（比如都改user(id=123)），MySQL 仍会强制塞进同一线程——这是为保一致性，不是 bug
如何验证并行复制真的在起作用？
不能只看 Seconds_Behind_Master 数值变小，要确认延迟下降来自 SQL 线程吞吐提升，而非 IO 线程或网络偶然变快。
- 对比关键指标：在从库执行
SHOW SLAVE STATUS\G，重点关注Seconds_Behind_Master、Read_Master_Log_Pos（IO 进度）、Exec_Master_Log_Pos（SQL 进度）三者差值变化趋势 - 查实际并发数：运行
SELECT COUNT(*) FROM performance_schema.replication_applier_status_by_worker WHERE LAST_ERROR_NUMBER = 0 AND WORKER_ID > 0，结果应接近你设的slave_parallel_workers值 - 观察 relay log 消费节奏：用
mysqlbinlog --base64-output=decode-rows -v relay-log-file | grep "last_committed"抽样看，相邻事务的last_committed是否成片相同——成片才代表有真实组提交
真正难的不是配置，而是让主库产生足够密集、冲突少的组提交事务；如果业务里大量单条 INSERT + COMMIT，或者频繁使用 autocommit=1，那再好的并行策略也救不了——这时候得配合应用层事务合并或批量写入。
