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生效。
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 不持久。
面向 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 核数，设太高会触发频繁上下文切换
真正容易被忽略的点是：即使所有参数都对，只要有一张被频繁写的表缺失主键，整个复制链路就会对涉及该表的所有事务降级为单线程——它不报错，只沉默地变慢。
