mysql 8.0主从复制更快的核心原因是writeset行级冲突检测绕开了5.7依赖组提交的脆弱瓶颈：5.7靠last_committed值判断并行，单线程写入或低峰期无法凑组即退化为串行；8.0则基于事务write_set哈希交集判定无冲突即可并行，使时间上分离但行级无重叠的事务也能并发回放。
MySQL 8.0 主从复制速度比 5.7 快，核心原因不是“整体更快”，而是在高并发写入、多表混改、低流量波动等真实业务场景下，SQL 线程回放不再轻易卡死。5.7 的并行能力高度依赖主库“凑组”，而 8.0 的 WRITESET 直接看行级变更是否冲突，绕开了组提交这个脆弱瓶颈。
为什么 5.7 的 LOGICAL_CLOCK 经常退化成单线程？
5.7 的并行逻辑只认一个值：last_committed。它由主库的组提交机制生成——只有在同一刷盘批次里的事务，才共享同一个 last_committed 值，从库才会把它们分发给不同 worker 并行执行。
- 定时任务批量更新单表：每次只发一条
UPDATE，last_committed几乎总是递增，SQL 线程只能串行回放 - 低峰期或单线程写入应用：事务间隔长，根本凑不成组，
Slave_SQL_Running_State长期卡在Waiting for an event from Coordinator -
binlog_group_commit_sync_delay调大能凑组，但会拖慢主库响应；调小又没效果，参数一换流量一变就失效 - 两个事务明明改的是不同表、不同行，只要没进同一组，照样不能并行
8.0 的 WRITESET 是怎么算出“能并行”的？
WRITESET 不再依赖主库是否“打包”，而是每个事务自己计算修改了哪些行的哈希值（基于主键或唯一键），把这些哈希存进一个集合（write_set），随 binlog 一起传到从库。从库用这个集合做交集判断：
- 事务 A 的 write_set = {hash(orders:1001), hash(users:201)}，事务 B 的 write_set = {hash(products:99)} → 无交集 → 可并行
- 事务 C 的 write_set = {hash(orders:1001), hash(logs:555)}，和 A 有交集 → 必须等 A 执行完再跑 C
- 即使 A 和 C 相隔 3 分钟提交，只要改的行不重叠，WRITESET 就能把它们调度进同一批 worker
这使得原本被时间割裂开的、无冲突的小事务，重新获得并行机会。
配置 WRITESET 必须设对这三项，缺一不可
WRITESET 不是开个开关就行，它是一套协作机制，主从配置必须匹配：
- 主库必须设：
binlog_transaction_dependency_tracking = WRITESET - 主库建议保持：
transaction_write_set_extraction = XXHASH64（默认值，别乱改） - 从库必须设：
slave_parallel_type = LOGICAL_CLOCK（注意：不是WRITESET！WRITESET 是 dependency tracking 模式，不是 parallel_type） - 从库还需开启：
slave_preserve_commit_order = ON（保证事务提交顺序与主库一致，避免幻读）
漏掉任意一项，比如误把 slave_parallel_type 设成 DATABASE，WRITESET 就完全不生效。
容易被忽略的兼容性雷区
WRITESET 对 DML 友好，但对某些操作天然失效，线上踩过坑的都记得：
- 没有主键或唯一键的表：无法生成稳定行级哈希，事务会被打上“全表依赖”标记，强制串行
- 涉及
TRIGGER或FUNCTION的事务：如果内部逻辑无法静态分析写集，也会退化为串行 - 使用
WRITESET_SESSION模式时：同一线程发起的所有事务强制保序，适合强一致性场景，但并行度直接砍半 - 升级后未重建表结构：5.7 升 8.0 若保留旧
.frm文件或未执行ALTER TABLE ... FORCE，可能导致元数据不一致，间接影响 write_set 计算
最隐蔽的一点：WRITESET 只作用于 ROW 格式 binlog。如果你的主库还开着 binlog_format = STATEMENT 或 MIXED，那所有优化都白搭——先确认 SELECT @@binlog_format 返回的是 ROW。
