MySQL 5.7 并行复制需同时满足多个硬性前提才能启用：slave_parallel_type必须显式设为'LOGICAL_CLOCK'，主库需启用GTID、ROW格式、WRITESET依赖追踪及binlog_order_commits=ON，从库元数据存储须为TABLE且relay_log_recovery=ON，否则worker线程不启动仍为单线程。
MySQL 5.7 并行复制不是设了 slave_parallel_workers 就自动跑起来的，绝大多数延迟没改善，是因为参数组合不满足硬性前提，worker 线程根本没启动。
为什么 slave_parallel_workers 设了还是单线程？
常见现象是 SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长期卡在 Reading event from the relay log，Seconds_Behind_Master 持续上涨——这说明 coordinator 没分发任务，worker 全空闲。
-
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）：组提交信息缺失，从库无法提取last_committed - 从库
master_info_repository或relay_log_info_repository仍是FILE：crash safe 退化，worker 启动失败或静默降级
slave_parallel_type = 'LOGICAL_CLOCK' 的生效条件
这个值必须显式设置，且大小写敏感：'LOGICAL_CLOCK' 不能写成 logical_clock 或 Logical_Clock，MySQL 会静默忽略。
- 必须先执行
STOP SLAVE，再SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'，否则报错 - 主库必须启用 GTID：
gtid_mode = ON且enforce_gtid_consistency = ON，否则从库无法可靠识别事务边界 - 主库
binlog_order_commits = ON（默认开启，但建议显式检查），否则组提交时间戳不连续 - 主库不能用已弃用的
DATABASE模式——它只按库名分发，单库业务完全无法并发
主库必须配套开启 WRITESET 依赖追踪
MySQL 5.7.22+ 支持更细粒度的并行判断，但需主库主动启用，否则仍退化为粗粒度的 COMMIT_ORDER。
- 检查命令：
SELECT @@binlog_format, @@binlog_transaction_dependency_tracking; - 主库必须设
binlog_format = ROW且binlog_transaction_dependency_tracking = WRITESET -
WRITESET模式下，并行依据是事务修改的行集合是否相交，和库名、表名无关；但要求binlog_row_image = FULL（默认值） - 注意：含
UUID()、NOW()等非确定函数的语句在MIXED格式下会退化为STATEMENT，破坏组提交连续性
配套元数据存储与 worker 数量设置
master_info_repository 和 relay_log_info_repository 必须设为 TABLE，否则 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，保证异常重启后中继日志一致性 -
slave_parallel_workers建议从 4 起步测试，逐步加到 8 或 12；不要超过从库 CPU 核心数，过高反而拖慢 coordinator 分发和冲突检测
最容易被忽略的是主库 binlog_transaction_dependency_tracking 和从库 relay_log_recovery 这两个配套项——它们不报错，但缺一不可；一旦漏掉，slave_parallel_workers 再大也只跑一个线程。
