应启用WRITESET并行复制策略：主库设binlog_transaction_dependency_tracking=WRITESET、binlog_format=ROW、transaction_write_set_extraction=XXHASH64，从库设slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers=8–16、slave_preserve_commit_order=ON，并确保GTID全链路开启（gtid_mode=ON且enforce_gtid_consistency=ON），最后通过performance_schema.replication_applier_status_by_worker验证多worker并发执行状态。
WRITESET 并行复制不会自动生效，哪怕你用的是 MySQL 8.0+，只要主从三处关键配置没对齐，SQL 线程照样串行回放，Seconds_Behind_Master 该涨还涨。
主库必须启用 WRITESET 依赖追踪
主库不生成 write_set，从库就无从判断行级冲突。默认的 COMMIT_ORDER 模式下，binlog 只记录 last_committed 和 sequence_number，没有哈希集合。
-
binlog_transaction_dependency_tracking必须设为WRITESET（不是WRITESET_SESSION，后者只对当前会话生效） -
binlog_format必须为ROW；MIXED在 DML 回退到STATEMENT时会丢失write_set -
transaction_write_set_extraction推荐用XXHASH64（比XXHASH32冲突率更低，尤其在大表场景）
从库必须匹配 LOGICAL_CLOCK 并行类型
容易误设成 slave_parallel_type = WRITESET——这根本不存在。MySQL 没有这个取值，设了会报错或静默忽略。
- 必须设为
LOGICAL_CLOCK：WRITESET 是依赖追踪策略（binlog_transaction_dependency_tracking），不是并行调度类型（slave_parallel_type） -
slave_parallel_workers建议设为 8–16，过高反而因协调开销拖慢整体速度 -
slave_preserve_commit_order = 1要保持开启：保证同一事务内多语句顺序，避免主键冲突等异常
GTID 必须开启且一致
WRITESET + GTID 是生产环境标配。没开 GTID，跳过错误事务要手动解析 relay log、找 position、执行 CHANGE MASTER TO，延迟恢复时间从秒级拉长到分钟级。
- 主从都需启用：
gtid_mode = ON且enforce_gtid_consistency = ON - 从库启动复制必须用
START SLAVE（不是START SLAVE IO_THREAD单启 IO） - 若复制中断，用
SET GTID_NEXT = 'xxx:yyy'; BEGIN; COMMIT;跳过即可，后续 GTID 自动对齐
验证是否真正生效
别只看 SHOW SLAVE STATUS\G 里的 Slave_SQL_Running_State 是否显示 “Reading event from the relay log”——这只能说明 SQL 线程活着，不能说明它在并发干活。
- 查
performance_schema.replication_applier_status_by_worker：确认多个WORKER_ID > 0的线程状态是APPLYING_EVENT，且LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP时间戳有明显交错 - 观察
SHOW PROCESSLIST中多个Worker线程是否同时处于活跃状态（非Waiting for an event from Coordinator） - 对比开启前后
Seconds_Behind_Master波动幅度：WRITESET 下延迟应更平稳，高峰时回落更快
最容易被忽略的一点：WRITESET 的效果高度依赖业务写模式。如果所有 DML 都集中在单表单行（比如计数器更新），再怎么配参数也并行不起来——因为 write_set 集合始终重叠。这时得从应用层拆分热点，而不是在复制参数上死磕。
