应启用writeset并行复制策略：主库设binlog_transaction_dependency_tracking=writeset且binlog_row_image=full，从库设slave_parallel_type=logical_clock、slave_parallel_workers=12–16，并验证performance_schema中多worker并发执行状态。
主从延迟严重时，先确认是否启用了并行复制
MySQL 8.0 默认的 binlog_transaction_dependency_tracking 是 COMMIT_ORDER，它依赖事务提交顺序推导依赖关系，对高并发写入场景下并行度提升非常有限，主从延迟往往卡在单线程回放上。必须手动切换到更高效的策略，否则调优其他参数意义不大。
检查当前设置：SELECT @@binlog_transaction_dependency_tracking;
常见错误现象：即使设置了 slave_parallel_workers > 0，SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master 仍持续上涨，且 Slave_SQL_Running_State 长时间停留在 “Reading event from the relay log” 或 “Waiting for dependent transaction to commit”。
-
WRITESET依赖写集（write set）——即事务修改的唯一键哈希值，只要不修改同一行（或同一主键/唯一键），就认为可并行；适合 OLTP、大量单行更新场景 -
LOGICAL_CLOCK依赖事务提交时间戳（由 coordinator 分配的逻辑时钟），并行粒度是“一组无冲突的事务”，但容易因大事务阻塞后续所有事务，实际并行度不如WRITESET
启用 WRITESET 的必要配置与验证步骤
WRITESET 不是开箱即用的：它要求主库生成 write set，从库才能据此调度并行回放。漏掉任一环节都会退化为单线程。
- 主库必须开启
binlog_transaction_dependency_tracking = WRITESET（动态生效） - 主库必须设置
binlog_row_image = FULL（默认值，但若被改过需确认）——否则无法准确提取 write set - 从库需设置
slave_parallel_type = LOGICAL_CLOCK（注意：不是WRITESET，这是历史命名遗留，实际支持 write set 调度） - 从库
slave_parallel_workers建议设为 CPU 核数的 1.5–2 倍（如 8 核设 12–16），但需观察Performance Schema中replication_applier_status_by_worker的空闲率
验证是否生效：SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE WORKER_ID != 0\G
若 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 和 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 有差异，且多个 worker 的 LAST_SEEN_TRANSACTION 不同，说明并行正在工作。
WRITESET 在什么情况下会失效？
write set 并非万能，它的并行能力高度依赖业务写模式。以下情况会导致事务被强制串行化：
- 事务修改了无主键、无唯一索引的表——MySQL 无法确定写集范围，降级为
COMMIT_ORDER行为 - 事务包含 DDL（如
ALTER TABLE）或跨库操作——直接标记为不可并行 - 事务中混用 statement 和 row 格式（如
sql_log_bin=OFF后又开启）——write set 无法生成 - 主库
binlog_transaction_dependency_tracking被动态改回COMMIT_ORDER或LOGICAL_CLOCK，新事务立即失去 write set
排查方法：SELECT COUNT(*) FROM performance_schema.replication_applier_status_by_worker WHERE LAST_SEEN_TRANSACTION LIKE '%:0';
若返回值接近 slave_parallel_workers，说明多数 worker 处于空闲等待状态，大概率是 write set 生效不足。
LOGICAL_CLOCK 为什么通常不如 WRITESET？
LOGICAL_CLOCK 在 MySQL 5.7 引入，8.0 中虽保留，但已明显落后于 WRITESET。它的核心问题是“全局逻辑时钟粒度太粗”：
- 一个大事务（如批量导入）会拉高其所在 clock group 的结束时间，导致后续所有事务排队等它完成
- 它不感知行级冲突，只看提交先后，因此在多表、多主键更新场景下并行度极低
- 无法利用主从分离架构中的读扩展优势——因为延迟压不下来，应用不敢切读流量到从库
典型表现：Seconds_Behind_Master 曲线呈锯齿状，每次大事务提交后延迟陡增，之后缓慢回落。而 WRITESET 下延迟更平滑，峰值更低。
真正复杂的地方在于：write set 效果高度耦合于表结构设计和 SQL 写法。比如一个没有主键的订单明细表，哪怕开了 WRITESET，所有 INSERT 都会被视为潜在冲突，全走单线程。这种细节，不查 information_schema.INNODB_TABLES 和慢日志，很容易忽略。
