MySQL并行复制默认不生效，必须同时满足主库binlog_format=ROW、从库slave_parallel_type='LOGICAL_CLOCK'、master_info_repository和relay_log_info_repository设为TABLE三重条件，否则slave_parallel_workers>0仍单线程回放。
MySQL 并行复制默认不生效，设了 slave_parallel_workers 也不等于真并行——必须同时满足主库日志格式、从库调度模式、元数据存储方式三重硬性条件，否则全是假并发。
为什么 slave_parallel_workers > 0 却没效果？
常见现象是 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%：
- 必须执行：
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 或事务粒度本身：
- 先确认主库是否真有组提交：查
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit%';，若Binlog_group_commit_trigger_count长期为 0，说明主库几乎无并发提交，从库自然没得并 - 从库上不要盲目设高值，建议初始设为 CPU 核心数的 2–4 倍（如 8 或 16），再结合
SHOW PROCESSLIST观察system user线程活跃度 - 监控重点不是线程数，而是
Seconds_Behind_Master是否稳定下降，以及Slave_SQL_Running_State是否频繁在Waiting for an event from Coordinator和Executing event之间切换
最容易被忽略的是：主库没开 GTID 或 binlog_format 退化，会让所有从库配置形同虚设；而 relay_log_recovery = OFF 会让 worker 在崩溃后无法正确续跑，导致延迟雪球式增长。
