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。但这个前提在真实业务里极难满足：
- 定时任务批量更新单表，每次只发一条
UPDATE，last_committed几乎总是递增 - 低峰期或单线程写入应用，事务间隔长，根本凑不成组
-
binlog_group_commit_sync_delay调大能凑组，但拖慢主库响应；调小又无效，流量一变就失效 - 两个事务明明改的是不同表、不同行，只要没进同一组，照样串行
结果就是 SHOW PROCESSLIST 中 Slave_SQL_Running_State 长时间卡在 Waiting for an event from Coordinator。
WRITESET 是怎么判断“能并行”的？
WRITESET 不看时间先后，只看行级变更是否冲突。每个事务在主库提交前，会基于其修改行的主键或唯一键计算哈希，生成一个 write_set 集合（如 {hash(orders:1001), hash(users:201)}），随 binlog 一起传到从库。从库用集合交集判定：
- 事务 A 和 B 的
write_set无交集 → 可并发执行 - 事务 A 和 C 的
write_set有交集（比如都含hash(orders:1001)）→ C 必须等 A 完成 - 即使 A 和 C 相隔 3 分钟提交，只要改的行不重叠，就能被调度进同一批 worker
这意味着原本被时间割裂开的、无冲突的小事务，重新获得并行机会。
配置 WRITESET 必须设对这三项，缺一不可
WRITESET 是主从协同机制，漏配任意一项，SQL 线程仍退化为串行：
- 主库必须设：
binlog_transaction_dependency_tracking = WRITESET（默认是COMMIT_ORDER，不设就无效） - 主库
binlog_format必须为ROW（MIXED在部分场景 fallback 到STATEMENT，导致write_set缺失） - 从库必须设：
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=...：
- 直接执行：
SET GTID_NEXT = 'xxx-xxx-xxx:12345'; BEGIN; COMMIT;即可跳过单个事务 - 跳过后 GTID 自动对齐后续事务，整个过程秒级完成
- 重启从库后，
GTID_EXECUTED自动识别已执行事务，无需依赖MASTER_AUTO_POSITION = 1以外的起点同步方式
但务必确认该事务在业务上可丢弃（比如幂等更新失败），且跳过前已验证无数据一致性风险——这是最容易被忽略的业务兜底环节。
