为什么MySQL 8.0的并行复制性能优于5.7版本？

MySQL 8.0并行复制性能优于5.7，核心在于WRITESET行级冲突检测绕开5.7依赖组提交的瓶颈：只要事务修改行无重叠（如不同主键值），即使时间分离、单线程写入或跨表操作，也能并行回放；而5.7的LOGICAL_CLOCK仅依赖last_committed值，需事务同组提交才可并行，低峰期或单表批量更新时极易退化为串行。

MySQL 8.0 的并行复制性能优于 5.7，不是因为“天生更快”，而是 WRITESET 行级冲突检测机制绕开了 5.7 依赖组提交的脆弱瓶颈——只要事务改的行不重叠，哪怕相隔几分钟、不同表、单线程写入，也能并行回放。

为什么 5.7 的 LOGICAL_CLOCK 经常退化成单线程？

5.7 的并行逻辑只认 last_committed 这一个值，它由主库组提交生成：只有同一刷盘批次的事务才共享该值，从库才分发给多个 worker。但这个前提在真实业务里极难满足：

1. 定时任务批量更新单表，每次只发一条 UPDATE，last_committed 几乎总是递增
2. 低峰期或单线程写入应用，事务间隔长，根本凑不成组
3. binlog_group_commit_sync_delay 调大能凑组，但拖慢主库响应；调小又无效，流量一变就失效
4. 两个事务明明改的是不同表、不同行，只要没进同一组，照样串行

结果就是 SHOW PROCESSLIST 中 Slave_SQL_Running_State 长时间卡在 Waiting for an event from Coordinator。

WRITESET 是怎么判断“能并行”的？

WRITESET 不看时间先后，只看行级变更是否冲突。每个事务在主库提交前，会基于其修改行的主键或唯一键计算哈希，生成一个 write_set 集合（如 {hash(orders:1001), hash(users:201)}），随 binlog 一起传到从库。从库用集合交集判定：

1. 事务 A 和 B 的 write_set 无交集 → 可并发执行
2. 事务 A 和 C 的 write_set 有交集（比如都含 hash(orders:1001)）→ C 必须等 A 完成
3. 即使 A 和 C 相隔 3 分钟提交，只要改的行不重叠，就能被调度进同一批 worker

这意味着原本被时间割裂开的、无冲突的小事务，重新获得并行机会。

配置 WRITESET 必须设对这三项，缺一不可

WRITESET 是主从协同机制，漏配任意一项，SQL 线程仍退化为串行：

1. 主库必须设：binlog_transaction_dependency_tracking = WRITESET（默认是 COMMIT_ORDER，不设就无效）
2. 主库 binlog_format 必须为 ROW（MIXED 在部分场景 fallback 到 STATEMENT，导致 write_set 缺失）
3. 从库必须设：slave_parallel_type = LOGICAL_CLOCK（注意：不是 WRITESET；WRITESET 是 dependency tracking 模式，不是 parallel_type）

常见错误是只改主库或只改从库，或者误把 slave_parallel_type 设成 WRITESET —— MySQL 8.0 会直接报错或静默降级。

GTID + WRITESET 组合如何减少人工干预延迟？

MySQL 8.0 强制推荐 gtid_mode = ON 与 enforce_gtid_consistency = ON。当从库 SQL 线程因唯一键冲突、表不存在等错误中断时，不再需要手动解析 relay log 找 position、执行 CHANGE MASTER TO RELAY_LOG_FILE=... POS=...：

1. 直接执行：SET GTID_NEXT = 'xxx-xxx-xxx:12345'; BEGIN; COMMIT; 即可跳过单个事务
2. 跳过后 GTID 自动对齐后续事务，整个过程秒级完成
3. 重启从库后，GTID_EXECUTED 自动识别已执行事务，无需依赖 MASTER_AUTO_POSITION = 1 以外的起点同步方式

但务必确认该事务在业务上可丢弃（比如幂等更新失败），且跳过前已验证无数据一致性风险——这是最容易被忽略的业务兜底环节。