怎么优化MySQL 8.0的WRITESET并行复制参数-mysql教程-PHP中文网

必须主库启用WRITESET依赖追踪且从库设LOGICAL_CLOCK模式，否则slave_parallel_workers无效；主库需binlog_format=ROW、gtid_mode=ON、binlog_row_image=FULL、表有主键/唯一键，从库需slave_preserve_commit_order=ON。

怎么优化mysql 8.0的writeset并行复制参数

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 在真正工作。