slave_parallel_type=LOGICAL_CLOCK是并行复制生效前提，需配合slave_parallel_workers、slave_preserve_commit_order及主库binlog_group_commit_sync_delay等参数协同优化，且大事务仍会阻塞并行。
slave_parallel_type=LOGICAL_CLOCK 是并行复制生效的前提
MySQL 5.7+ 的多线程复制不是“开个开关就自动并行”，必须明确启用 slave_parallel_type = LOGICAL_CLOCK。设为 DATABASE（默认兼容值）只在多库场景下有效，单库多表几乎无加速效果；而 LOGICAL_CLOCK 基于主库的组提交（group commit）信息，能识别事务间的逻辑依赖关系，让真正可并行的事务分发到不同 worker 线程执行。
常见错误是只调了 slave_parallel_workers 却没改 slave_parallel_type，结果 SHOW PROCESSLIST 里仍只看到一个 SQL thread，performance_schema.replication_applier_status_by_worker 也查不到多个 worker 记录。
worker 线程数不是越多越好，需匹配硬件与负载
slave_parallel_workers 设为 8 或 16 并不意味着性能翻倍。它受限于从库 CPU 核心数、磁盘 I/O 吞吐和 relay log 解析开销。实测中，超过 CPU 核心数 2 倍后，线程上下文切换和锁竞争反而拖慢整体回放速度。
- SSD + 16 核 CPU 的从库，
slave_parallel_workers = 8通常是较优起点 - 如果从库还承担大量读请求，建议压测时观察
Threads_running和Innodb_row_lock_waits，避免 worker 线程加剧锁争用 - 务必开启
slave_preserve_commit_order = ON，否则跨线程提交顺序错乱会导致主从数据不一致（尤其在 GTID 模式下可能触发复制中断）
主库 binlog_group_commit_sync_delay 配合才起效
从库能并行，前提是主库把可并行的事务“打包”进同一个 binlog group。若主库 binlog_group_commit_sync_delay = 0（默认），高并发小事务容易被拆成单事务组，从库 worker 就只能串行消费——看起来开了并行，实际还是单线程节奏。
合理设置主库参数才能激活 MTS 效能：
-
binlog_group_commit_sync_delay = 100（单位微秒）：允许短暂等待，攒够事务再刷盘 -
binlog_group_commit_sync_no_delay_count = 10：凑够 10 个事务也立即提交，防止单个事务卡太久 - 必须确保
binlog_format = ROW；MIXED或STATEMENT下，逻辑时钟信息不完整，MTS 退化为低效模式
大事务仍是并行复制的“拦路虎”
哪怕所有参数都配对，一个运行 30 分钟的 DELETE FROM huge_table WHERE ... 在从库仍只能由单个 worker 执行——整个并行队列会卡在这个事务上，后续所有事务排队等待。这不是配置问题，而是架构限制：事务不可拆分，必须原子执行。
应对方式不是调参数，而是业务侧干预：
- 监控主库长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 60 - 批量操作强制分页：
DELETE FROM t WHERE id BETWEEN ? AND ? LIMIT 10000，每批加SLEEP(0.1) - DDL 操作禁用隐式锁表：用
pt-online-schema-change替代直接ALTER TABLE，避免阻塞后续事务分发
并行复制能缓解延迟，但不能绕过事务本质。真正难啃的延迟，往往藏在那个没人敢动的大事务里。
