必须设为WRITESET，否则slave_parallel_workers再高也基本无效；因COMMIT_ORDER仅按提交时间判断依赖，无视行级冲突，致同连接多语句强制串行回放，而WRITESET需主库binlog_transaction_dependency_tracking=WRITESET、ROW格式、FULL行镜像及唯一键，从库slave_parallel_type=LOGICAL_CLOCK方可生效。
必须设为 WRITESET，否则 slave_parallel_workers 再高也基本无效。
为什么 COMMIT_ORDER 模式下并行几乎不工作
MySQL 8.0 默认用 COMMIT_ORDER，它只看事务提交时间是否重叠，完全不检查“改了哪几行”。同一连接里连续执行的 UPDATE user SET balance = ... 和 INSERT INTO order，哪怕操作不同表、不同行，也会被判定为强依赖，只能排队回放。
常见现象包括：
-
SHOW SLAVE STATUS\G中Slave_SQL_Running_State长期卡在Waiting for preceding transaction to commit -
performance_schema.replication_applier_status_by_coordinator里WORKERS_WAITING远高于WORKERS_PROCESSED - 即使
slave_parallel_workers = 16，SHOW PROCESSLIST也只看到 1–2 个Slave_worker在活跃
启用 WRITESET 的硬性前提
WRITESET 不是开个参数就生效的，漏掉任一条件都会静默退化回 COMMIT_ORDER：
- 主库必须设
binlog_transaction_dependency_tracking = 'WRITESET'（推荐用SET PERSIST持久化） - 主库
binlog_format必须为ROW（STATEMENT或MIXED直接禁用写集） - 主库
binlog_row_image必须为FULL（MINIMAL会导致写集提取失败） - 主库表必须有
PRIMARY KEY或NOT NULL UNIQUE KEY（无唯一键 → 写集为空 → 自动 fallback） - 从库
slave_parallel_type必须为LOGICAL_CLOCK（注意：不是WRITESET，这是命名遗留）
验证是否真正生效的关键指标
别只查参数值，要看运行时行为：
- 主库执行：
SELECT @@binlog_transaction_dependency_tracking, @@binlog_format, @@binlog_row_image;—— 三者应为'WRITESET'、'ROW'、'FULL' - 从库查：
SELECT * FROM performance_schema.replication_applier_status_by_worker WHERE WORKER_ID != 0\G—— 多个 worker 的LAST_SEEN_TRANSACTION应各不相同，且LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP有明显时间差 - 从库
SHOW PROCESSLIST应稳定看到 ≥4 个Slave_worker处于Waiting for an event from Coordinator或正在执行 SQL
最容易被忽略的是：主库没配 WRITESET，但从库 slave_parallel_workers 却调得很高——这只会增加线程调度开销，不提升实际吞吐。
