mysql 5.7并行复制需同时满足主库row格式、binlog_transaction_dependency_tracking=writeset，从库slave_parallel_type=logical_clock且slave_preserve_commit_order=off，否则slave_parallel_workers设置无效。
MySQL 5.7 的并行复制不是设了 slave_parallel_workers 就自动生效的，必须同时满足主从两端的多个硬性条件，否则值设成 16 也只跑 1 个线程。
确认主库 binlog 格式和依赖追踪方式
并行复制依赖主库生成的 last_committed 和 sequence_number，这两个字段只在特定配置下写入：
-
binlog_format必须为ROW（MIXED或STATEMENT不产生组提交信息） -
binlog_transaction_dependency_tracking必须为WRITESET（比默认的COMMIT_ORDER更细粒度，支持跨表并行） - 主库需开启
log_bin，且建议打开log_slave_updates（方便级联复制）
检查命令：SELECT @@binlog_format, @@binlog_transaction_dependency_tracking;
不满足就改主库配置，重启或动态设置（5.7.20+ 支持动态修改 binlog_transaction_dependency_tracking）。
从库必须启用 LOGICAL_CLOCK 模式
slave_parallel_type = DATABASE 是默认值，但它只按库分发事务——如果主库所有写都在一个库（比如 app_db），那无论 slave_parallel_workers 设多少，实际只有 1 个 worker 在干活。
必须显式切换为逻辑时钟模式：
- 动态执行：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; - 该操作需先
STOP SLAVE，否则报错 - 确认生效：
SHOW VARIABLES LIKE 'slave_parallel_type';返回LOGICAL_CLOCK
注意大小写：'LOGICAL_CLOCK' 不能写成 'logical_clock' 或 'Logical_Clock'，MySQL 会静默忽略。
合理设置 slave_parallel_workers 数值
这个值不是越大越好，它受限于真实可并行的事务组数量和从库 CPU 资源：
- 建议从
4起步测试，逐步加到8或12，但不要超过从库 CPU 核心数 - 设得过高反而拖慢：Coordinator 线程要频繁做事务分发、冲突检测和等待，尤其在有热点表或大量主键冲突时
- 长事务（>30s）会阻塞整个并行队列，因为后续事务的
last_committed无法推进 - 检查是否真正启用：
SHOW PROCESSLIST;应看到多个Worker线程（状态为Waiting for an event from Coordinator）
设置命令：SET GLOBAL slave_parallel_workers = 4;（同样需先 STOP SLAVE）
别忽略 slave_preserve_commit_order 的影响
这个参数控制从库是否强制保持事务提交顺序。5.7.22+ 默认是 OFF，但如果被设为 ON，它会禁用并行回放——所有 worker 必须串行等待前一个提交完成，等于关掉了并行复制。
检查与修正：
-
SELECT @@slave_preserve_commit_order;—— 若返回1，立即关掉：SET GLOBAL slave_preserve_commit_order = OFF; - 该参数是只读变量（5.7.22+），只能在配置文件中设置，或通过
SET GLOBAL动态关闭（需有 SUPER 权限） - 关掉后无需重启，但需
STOP/START SLAVE才能生效
真正起效的并行复制，是 coordinator 把 last_committed 相同的一组事务分发给不同 worker 并发执行；任何强制保序机制都会打断这个流程。
