必须同时满足主库writeset配置、从库logical_clock+worker>0、表有主键、binlog_row_image=full等条件，缺一则退化单线程；常见因主库未开writeset或表无主键导致workers_processed不增长。
为什么 slave_parallel_type=LOGICAL_CLOCK 还是单线程回放
常见现象是 SHOW SLAVE STATUS\G 里 Slave_SQL_Running_State 长期卡在 “Reading event from the relay log”，Seconds_Behind_Master 持续上涨，但 performance_schema.replication_applier_status_by_coordinator 中 WORKERS_PROCESSED 基本不增长——说明并行复制根本没跑起来。
根本原因不是参数没设，而是几个关键条件缺一不可：
-
slave_parallel_type必须为'LOGICAL_CLOCK'（不能是'DATABASE'） -
slave_parallel_workers必须 > 0，建议设为 CPU 核数 × 1.5（如 8 核设 12） - 主库必须开启
binlog_transaction_dependency_tracking=WRITESET（MySQL 8.0.26+ 推荐） - 主库需配
transaction_write_set_extraction=XXHASH64 - 主库
binlog_row_image必须为FULL（MINIMAL会导致写集提取失败） - 涉及的表必须有主键或非空唯一键（否则写集为空，自动退化为单线程）
改完必须重启复制链路：STOP SLAVE; START SLAVE;，仅 SET GLOBAL 不触发重载。
WRITESET 下为什么还会锁冲突
启用 WRITESET 后，从库会基于事务修改的主键/唯一键哈希值判断是否可并行。但冲突仍会发生，典型场景包括：
- 多个事务更新同一张表的同一行（主键值相同 → 写集交集非空 → 强制串行）
- 事务含 DDL（如
ALTER TABLE），这类操作始终阻塞所有后续事务 - 大事务长期持有行锁，导致后续依赖该行的事务排队等待
- 从库
innodb_lock_wait_timeout设置过小，短时锁等待直接报错中断复制
这不是配置错误，而是数据变更逻辑本身存在真实依赖。此时强行提高并行度无用，应优先拆分大事务、避免跨分片/跨业务聚合更新。
如何验证并行复制是否真正在工作
别只看 Seconds_Behind_Master 是否下降，要查底层执行状态：
- 运行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G，确认WORKERS_PROCESSED在持续增长（不是恒为 0 或缓慢爬升） - 查
performance_schema.replication_applier_status_by_worker，看各 worker 的LAST_APPLIED_TRANSACTION是否分散在不同 GTID 上（说明真正并发执行） - 观察
SHOW PROCESSLIST，SQL 线程应显示多个Worker进程，而非仅一个Coordinator
如果 WORKERS_PROCESSED 长期不动，90% 是表缺失主键或主库未开 WRITESET ——这时调 slave_parallel_workers 到 100 也没用。
slave_preserve_commit_order 开还是关
这个参数控制从库是否严格按主库提交顺序输出 binlog（影响级联复制和 GTID 连续性）。但它会显著压制并行效果：
- 设为
ON：即使事务 A 和 B 无写集冲突，也必须等 A 完全提交后才允许 B 提交 → 实际并发度大幅下降 - 设为
OFF：A、B 可真正同时提交 → 并行吞吐提升，但级联从库可能看到 GTID 乱序（只要不依赖该顺序，问题不大）
如果你的架构是“主库 → 直连从库”，且不用于再同步（即从库不开启 log_slave_updates），建议设为 OFF。若启用了级联复制，则必须 ON，但要接受性能折损。
真正容易被忽略的是：这个参数默认值在 MySQL 8.0 是 ON，很多人开了 MTS 却没意识到它正在悄悄拖慢速度。
