必须主库启用WRITESET依赖追踪且从库设LOGICAL_CLOCK模式，否则slave_parallel_workers无效；主库需binlog_format=ROW、gtid_mode=ON、binlog_row_image=FULL、表有主键/唯一键，从库需slave_preserve_commit_order=ON。
WRITESET 并行复制不是设了 slave_parallel_workers 就能跑起来的——主库没配对，从库再调也白搭。
主库必须显式开启 WRITESET 依赖追踪
MySQL 8.0 默认用 COMMIT_ORDER，事务之间只靠提交时间戳分组，单 session 高并发下基本无法并行。必须在主库执行：
-
SET PERSIST binlog_transaction_dependency_tracking = 'WRITESET';（全局生效，WRITESET_SESSION只对当前会话有效，不推荐） -
SET PERSIST transaction_write_set_extraction = 'XXHASH64';（比XXHASH32冲突率更低） -
SET PERSIST binlog_transaction_dependency_history_size = 25000;（太小会挤掉旧写集，导致误判冲突）
漏掉任意一项，从库收不到带 write_set 的 binlog 事件，slave_parallel_workers 就是摆设。
从库不能设 slave_parallel_type = 'WRITESET'
这是最常踩的坑：WRITESET 是主库的依赖追踪策略，不是从库的并行调度类型。MySQL 根本没有 slave_parallel_type = 'WRITESET' 这个合法取值——设了会报错或静默回退到 DATABASE 模式，只跑 1 个 worker。
从库正确配置是：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';（MySQL 8.0.22+ 虽支持'WRITESET'，但仅限极少数内部场景，不推荐） -
SET GLOBAL slave_parallel_workers = 8;（先从 4 或 8 起步，别直接设 16+；观察performance_schema.replication_applier_status_by_worker中活跃 worker 数） -
SET GLOBAL slave_preserve_commit_order = ON;（必须开，否则可能因乱序提交引发主键冲突或脏读）
表结构和 binlog 配置是硬门槛
WRITESET 依赖行级写集哈希，而哈希需要能唯一标识每一行——所以：
- 每张参与复制的表必须有
PRIMARY KEY或NOT NULL UNIQUE KEY；否则事务自动 fallback 到COMMIT_ORDER，且 MySQL 不报任何警告 -
binlog_row_image必须为FULL或MINIMAL（NONE会导致写集字段缺失） -
binlog_format必须为ROW（STATEMENT或MIXED下 WRITESET 不生效） -
gtid_mode = ON且enforce_gtid_consistency = ON（WRITESET 依赖 GTID 定位事务）
DDL 操作（如 ALTER TABLE）会清空写集缓存，后续事务全部串行——这类语句要避开业务高峰。
验证是否真生效，别只看 Seconds_Behind_Master
延迟下降可能是网络或 IO 改善，不代表并行真的跑起来了。要看实时运行态：
- 查
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;，重点看APPLIED_TRANSACTIONS_IMMEDIATE占比；如果长期接近 0，说明几乎没并行事务被调度 - 查
SELECT * FROM performance_schema.replication_applier_status_by_worker;，确认多个PROCESS_ID非空、LAST_APPLIED_TRANSACTION值分散 - 用
mysqlbinlog --base64-output=decode-rows -v解析主库 binlog，确认事务 event 中含write_set字段
最容易被忽略的是：主库 CPU 开销会上升（计算 writeset hash），高并发写入下得盯住 Cpu_usage 是否明显跳变——这不是配置错误，而是 WRITESET 在真正工作。
