必须将slave_parallel_type设为'logical_clock'，主库开启binlog_transaction_dependency_tracking=writeset、binlog_row_image=full、表有主键或唯一键，且执行stop/start slave后并行复制才生效，否则仍单线程。
为什么设了slave_parallel_workers还是单线程回放
常见现象是SHOW SLAVE STATUS\G里Slave_SQL_Running_State卡在 “Reading event from the relay log”，Seconds_Behind_Master持续上涨，但performance_schema.replication_applier_status_by_coordinator中WORKERS_PROCESSED几乎不增长——说明并行复制根本没跑起来。
这不是slave_parallel_workers没设对，而是以下任一条件缺失都会导致退化为单线程：
-
slave_parallel_type必须为'LOGICAL_CLOCK'（不是'DATABASE'） - 主库未开启
binlog_transaction_dependency_tracking=WRITESET（MySQL 8.0.26+ 推荐） - 主库
transaction_write_set_extraction未设为XXHASH64 - 主库
binlog_row_image不是FULL（MINIMAL会导致写集提取失败） - 涉及的表没有主键或非空唯一键（写集为空，强制串行）
- 改完参数后未执行
STOP SLAVE; START SLAVE;（仅SET GLOBAL不触发线程重建）
slave_parallel_workers设多少才合适
这个值代表从库启动的 SQL 工作线程数，但实际并发效果受 CPU、磁盘 IO 和 relay log 读取能力制约，不是越大越好。
- 建议初始值设为 CPU 逻辑核数的 70%～100%，例如 8 核机器设
6或8，别直接拉到16 - 若从库磁盘 IO 能力弱（如 SATA SSD 或 HDD），设过高反而加剧写入竞争，
innodb_log_writes和fsync成瓶颈 - 执行
SHOW PROCESSLIST能看到多个Worker thread，但若Seconds_Behind_Master没下降，说明瓶颈不在 SQL 层，而在 IO 线程或磁盘刷盘 - 动态调整后必须
STOP SLAVE; START SLAVE;才生效，否则线程数不变
WRITESET 启用后为什么还有锁冲突
启用 WRITESET 后，并行判断基于事务修改的主键/唯一键哈希值，但真实锁冲突仍会发生，这是数据变更逻辑本身决定的，不是配置缺陷。
- 多个事务更新同一张表的同一行（主键值相同 → 写集交集非空 → 强制串行）
- 事务含 DDL（如
ALTER TABLE），这类操作始终阻塞所有后续事务 - 大事务长期持有行锁，导致后续依赖该行的事务排队等待
- 从库
innodb_lock_wait_timeout设置过小（如默认 50 秒），短时锁等待直接报错中断复制 - 此时提高
slave_parallel_workers无用，应优先拆分大事务、避免跨业务聚合更新
如何验证并行复制是否真正生效
不能只看 slave_parallel_workers 值或线程数量，要观察实际工作负载分布和位点推进节奏。
- 查
performance_schema.replication_applier_status_by_worker，确认各WORKER_ID的LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP是否有时间差，且COUNT_TRANSACTIONS_RETRIES不持续飙升 - 对比
Exec_Master_Log_Pos在一段时间内的推进速度：单线程下每秒推进可能只有几 KB；并行正常时可达 MB/s 级别（取决于主库写入压力） - 监控
Replica_running_state中是否频繁出现 “Waiting for dependency” 类状态，这表示 WRITESET 正在做依赖判断，而非卡死 - 注意：低流量时段（如凌晨）
last_committed几乎全递增，LOGICAL_CLOCK会自然退化为单线程，这不是故障，是设计使然
slave_parallel_workers，而是让主库能打出足够多的可并行事务组，再配合从库正确识别与分发。中间任何一个环节断链，比如表缺主键、主库没开 WRITESET、或者大事务把整个流水线堵住，数值再大也只是空转。
