必须同时启用gtid、row格式、log_slave_updates和slave_parallel_type=writeset，否则即使设置slave_parallel_workers>0，mysql仍会降级为单线程回放；漏掉任一前提条件（如binlog_format非row、gtid_mode=off、log_slave_updates=off），并行复制即失效。
MySQL 8.0 主从延迟高，光靠调大 slave_parallel_workers 没用 —— 必须同时开启 log_slave_updates 并配对启用 GTID 和 ROW 格式，否则并行线程根本不会启动。
为什么 slave_parallel_workers 设了 8 却还是单线程回放？
常见现象：执行 SHOW PROCESSLIST 只看到一个 SQL Thread，slave_parallel_workers 显示为 8，但 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 持续上涨。
根本原因不是参数没生效，而是并行复制的前提条件未满足：
-
binlog_format必须是ROW（STATEMENT/MIXED 不支持 writeset 并行） -
gtid_mode = ON且enforce_gtid_consistency = ON（MySQL 8.0 的 writeset 依赖 GTID） -
log_slave_updates = ON（看似和并行无关，实则影响slave_preserve_commit_order的行为逻辑） - 从库的
slave_parallel_type必须设为LOGICAL_CLOCK或WRITESET（MySQL 8.0.22+ 支持后者）
漏掉任意一项，MySQL 会自动降级回单线程 SQL 回放，slave_parallel_workers 形同虚设。
log_slave_updates = ON 在并行复制里到底起什么作用？
它不直接触发并行，但它是 slave_preserve_commit_order = 1 能生效的前提。这个参数控制“从库是否把主库发来的变更写进自己的 binlog”——而 MySQL 8.0 的 writeset 并行机制，需要在 relay log 解析阶段就识别事务间写集（writeset）冲突，这依赖于完整的 GTID + binlog 事件链。
如果 log_slave_updates = OFF：
- 从库 SQL 线程执行完 relay log 后，不生成对应 binlog 事件
-
slave_preserve_commit_order无法校验跨事务的 writeset 依赖关系 - 即使设了
slave_parallel_type = WRITESET，MySQL 也会静默回退到LOGICAL_CLOCK，甚至单线程
所以生产环境配并行复制时，log_slave_updates 不是“可选”，而是强制项，哪怕你当前没做级联复制。
MySQL 8.0 并行复制实操配置清单
以下操作需在从库执行，主库仅需确认 binlog_format = ROW 和 gtid_mode = ON 已启用：
- 停复制：
STOP SLAVE; - 设并行类型：
SET GLOBAL slave_parallel_type = 'WRITESET';（推荐，比LOGICAL_CLOCK更细粒度） - 开并行数：
SET GLOBAL slave_parallel_workers = 4;（建议设为 CPU 核数的 75%，避免争抢） - 保序关键：
SET GLOBAL slave_preserve_commit_order = 1;（防止主从数据瞬时不一致） - 确认日志转发：
SET GLOBAL log_slave_updates = ON;（必须，且需写入my.cnf永久生效） - 重启生效：
START SLAVE;
验证是否真正并行：SHOW PROCESSLIST; 应看到多个 Worker thread；再查 SHOW SLAVE STATUS\G，确认 Slave_SQL_Running_State 显示 “Waiting for dependent transaction to commit” 或类似并发状态。
容易被忽略的性能陷阱
并行复制不是万能加速器，以下三点常被跳过，导致延迟反而恶化：
-
slave_parallel_workers > 0但磁盘 I/O 跟不上：writeset 解析和多线程写 relay log 会显著增加随机写压力，SSD 是硬性要求，机械盘上开 4 个 worker 可能比 1 个还慢 - 主库
binlog_group_commit_sync_delay设得过大（如 10000 微秒），人为拉长事务提交间隔，从库接收节奏变慢，抵消并行收益 - 从库启用了
innodb_flush_log_at_trx_commit = 1+sync_binlog = 1，双写强刷模式下，多线程并发刷盘反而引发锁争抢，此时应权衡一致性与吞吐，考虑设为innodb_flush_log_at_trx_commit = 2
最隐蔽的问题是：开了 WRITESET 并行后，Seconds_Behind_Master 数值可能“跳变”（忽高忽低），这不是异常，而是 writeset 冲突检测导致部分事务排队等待 —— 关键看平均延迟是否下降，而非瞬时值。
