mysql 5.7并行复制默认不生效，因slave_parallel_workers=0即单线程回放，设为1反降性能20%；必须同时满足主库binlog_format=row、从库slave_parallel_type='logical_clock'、master_info_repository和relay_log_info_repository设为table三重条件才真正启用。
MySQL 5.7 并行复制默认不生效，slave_parallel_workers=0 就是单线程回放，设成 1 反而更慢——必须同时满足主库日志格式、从库类型、元数据存储三重条件，才能真正跑起来。
为什么 slave_parallel_workers 设了还是不并行？
这不是“开了就跑”，而是整个链路卡在某个环节。常见现象是 SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长期停在 Reading event from the relay log，Seconds_Behind_Master 持续上涨。
-
slave_parallel_workers = 0：纯单线程 SQL 线程直接回放，没 coordinator + worker 架构 -
slave_parallel_workers = 1：coordinator 存在但只配一个 worker，事务仍串行，实测比 = 0 慢约 20% -
slave_parallel_workers > 1且slave_parallel_type != 'LOGICAL_CLOCK'：参数被忽略，降级为单线程 - 主库
binlog_format不是ROW（比如用了MIXED或STATEMENT）：事务依赖信息缺失，从库无法分组
slave_parallel_type=LOGICAL_CLOCK 的硬性前提
这个值不是“自动识别并行”，而是依赖主库写入时打上的 last_committed 和 sequence_number 时间戳。缺一不可：
- 主库必须设
binlog_format = ROW；MIXED在含UUID()、NOW()的语句下会退化为STATEMENT，破坏组提交连续性 - 主库需确认
binlog_order_commits = ON（默认开启，但建议显式检查） - 从库不能用已弃用的
DATABASE模式——它只按库名分发，单库业务完全无法并发 - 主库必须开启 GTID：
gtid_mode = ON且enforce_gtid_consistency = ON，否则从库无法可靠识别事务边界
关键配套参数必须设为 TABLE
master_info_repository 和 relay_log_info_repository 默认是 FILE，这会导致 crash safe 退化、worker 恢复时可能重复或跳过事务，且性能下降 50%–80%。
- 必须设为
TABLE：SET GLOBAL master_info_repository = 'TABLE';，SET GLOBAL relay_log_info_repository = 'TABLE'; - 设完后原
master.info和relay-log.info文件会被删除，信息存入mysql.slave_master_info和mysql.slave_relay_log_info - 配套启用
relay_log_recovery = ON，保证从库异常重启后能自动恢复中继日志一致性
worker 数量和监控怎么看才准？
设 16 个 worker 不等于吞吐翻 16 倍，瓶颈常在 I/O 或 SQL 回放本身。别只盯 Seconds_Behind_Master——它只反映时间差，不代表真实追平。
- 合理值范围：4–8（多数 OLTP 场景），最多设到 CPU 核心数的 2–4 倍（如 16 核设 8–16），再高会引发上下文切换开销
- 查真实并行效果：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G，看WORKERS_PROCESSED是否持续增长 - 更准的追平判断：主库执行
SELECT UNIX_TIMESTAMP();，从库执行SELECT MASTER_POS_WAIT('<code>binlog_file', pos, 0);（用SHOW MASTER STATUS当前位点），返回 0 才算真正追平 - 如果
Slave_SQL_Running_State长期是Waiting for dependent transaction to commit，说明 write-set 依赖检测在起作用，但主库事务粒度太粗（比如单事务改几百行），反而成了瓶颈
最容易被忽略的是主库是否真有组提交——binlog_group_commit_sync_delay=0 且 binlog_group_commit_sync_no_delay_count 过大，会导致事务几乎串行提交，从库看到的 last_committed 值高度重复，worker 空转。调优必须从主库开始，不能只动从库参数。
