怎样在MySQL8.0中配置多线程复制slave_parallel

MySQL设了slave_parallel_workers仍单线程，是因未满足WRITESET并行硬性前提：主库binlog_format=ROW、binlog_transaction_dependency_tracking=WRITESET、binlog_row_image=FULL，且表须有主键或非空唯一键；从库需slave_parallel_type=LOGICAL_CLOCK、log_slave_updates=ON、slave_preserve_commit_order=ON，并执行STOP/START SLAVE生效。

怎样在mysql8.0中配置多线程复制slave_parallel_workers

slave_parallel_workers设了为什么还是单线程？

不是参数没生效，而是 MySQL 主动降级回单线程——它检测到事务之间存在逻辑依赖，为保一致性，自动放弃并行。常见现象包括：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长期卡在 Waiting for preceding transaction to commit；performance_schema.replication_applier_status_by_worker 里多数 worker 状态是 Waiting for an event from Coordinator，且 WORKERS_PROCESSED 几乎不增长。

根本原因通常有这些：

binlog_format 不是 ROW（STATEMENT 或 MIXED 下 WRITESET 直接失效）
主库未启用 binlog_transaction_dependency_tracking = 'WRITESET'（默认是 COMMIT_ORDER，只看提交时间，无法识别行级并发）
被修改的表没有 PRIMARY KEY 或非空 UNIQUE KEY（导致写集为空，自动 fallback）
从库 slave_preserve_commit_order = ON（MySQL 8.0.27+ 默认开启），它会强制按主库顺序提交，worker 实际串行等待

主库必须配齐的三项 WRITESET 基础

仅在从库设 slave_parallel_workers > 0 没用。WRITESET 并行能力完全依赖主库输出“可并行的事务组”，缺一不可：

binlog_format = ROW（必须，MIXED 也不行）
gtid_mode = ON 且 enforce_gtid_consistency = ON（GTID 是组提交和依赖跟踪的前提）
binlog_transaction_dependency_tracking = 'WRITESET'（核心开关，配合 transaction_write_set_extraction = 'XXHASH64' 和 binlog_row_image = 'FULL'）

执行方式（主库）：

SET PERSIST binlog_transaction_dependency_tracking = 'WRITESET';
SET PERSIST transaction_write_set_extraction = 'XXHASH64';
SET PERSIST binlog_row_image = 'FULL';

注意：binlog_row_image = 'MINIMAL' 会导致写集提取失败，直接退化；改完建议重启 MySQL 或确认 my.cnf 已同步，某些版本 PERSIST 不持久。

从库关键配置与动态生效步骤

从库侧不负责生成写集，但要正确消费。必须确保：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

slave_parallel_type = 'LOGICAL_CLOCK'（MySQL 8.0 默认已是该值，5.7 需显式设；DATABASE 模式在单库场景下基本无效）
log_slave_updates = ON（否则 slave_preserve_commit_order 无法生效，WRITESET 会退化）
slave_preserve_commit_order = ON（保持开启，这是数据一致性的底线；关掉它可能引发脏读，不是提速手段）

动态调整 slave_parallel_workers 的正确姿势：

STOP SLAVE;
SET GLOBAL slave_parallel_workers = 8;
START SLAVE;

只执行 SET GLOBAL 不停复制，参数不会生效；重启 MySQL 也不影响已设置的全局值，但需确保配置文件中也写入，避免重启丢失。

slave_parallel_workers 设多少才合理？

不是越多越好，更不是照搬 CPU 核数。关键看主库每秒能打出多少个可并行的事务组（即 Binlog_group_commit 频率）。实操判断方法：

在主库查：SHOW GLOBAL STATUS LIKE 'Binlog_group_commit%'，观察 Binlog_group_commit_trigger_count 每秒增量
若平均每秒 3–5 组，slave_parallel_workers = 4 足够；超 10 组再考虑调至 8 或 12
勿设超过 16：MySQL 8.0 对 >16 个 worker 的调度优化有限，反而因锁竞争拖慢整体 SQL 线程
RDS 场景下还要受限于只读实例的 CPU 核数，设太高会触发频繁上下文切换

真正容易被忽略的点是：即使所有参数都对，只要有一张被频繁写的表缺失主键，整个复制链路就会对涉及该表的所有事务降级为单线程——它不报错，只沉默地变慢。