必须同时设置slave_parallel_type=LOGICAL_CLOCK和slave_parallel_workers>0才生效，仅设workers无效；主库需binlog_format=ROW且建议启用GTID，否则并行复制无法稳定运行。
直接设置 slave_parallel_workers 大于 0 是开启多线程复制的必要动作，但不是充分条件。真正生效并稳定破除延迟，需要主从协同配置、事务特征适配和状态持续观察。
基础配置必须到位
仅改一个参数无法启动并行复制：
- 从库必须设
slave_parallel_type = LOGICAL_CLOCK（MySQL 8.0 默认已满足，5.7 需显式执行SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'） - 主库必须启用
binlog_format = ROW，否则逻辑时钟信息（last_committed/sequence_number）不会写入 binlog - 强烈建议主从都启用 GTID（
gtid_mode = ON），避免位置偏移导致的并行中断；若不用 GTID，至少确保relay_log_info_repository = TABLE和master_info_repository = TABLE - 动态设置立即生效：
SET GLOBAL slave_parallel_workers = 8;；如需永久生效，加到 my.cnf 的[mysqld]段并重启
为什么设了却还是单线程回放？
MySQL 主动降级是常态，不是故障：
- 同一组事务若
last_committed值相同，才可并行；若主库因锁等待、大事务或无主键 UPDATE 导致组提交失败，所有事务会被压进同一个 group，从库只能串行回放 - 典型诱因：批量
INSERT ... SELECT、CREATE TABLE AS SELECT、对无主键/唯一键表的并发 UPDATE - 验证是否真并行：
SHOW PROCESSLIST查看是否有多个Slave_worker线程；或查performance_schema.replication_applier_status_by_worker看各 worker 的LAST_APPLIED_TRANSACTION是否在推进
线程数不是越多越好
盲目调高反而加剧延迟：
- 推荐值范围：4–12，优先参考从库 CPU 逻辑核数（如 8 核机器设为 8，16 核可试 12）
- 纯 OLTP 小事务场景且 I/O 充足，可设为逻辑核数的 1–2 倍；若有定期大事务（如夜间导入、DDL），保守设为 4–6，避免 worker 频繁空等或争抢锁资源
- 绝对不要设为 0（退化为单线程）或 1（仍启 coordinator 架构，但无实际并行收益）
配套优化不能少
光靠并行复制难治本，需结合主库行为调整：
- 主库开启
binlog_group_commit_sync_delay（如 100000 微秒），人为“攒”事务进同一 group，提升从库可并行事务比例 - 排查并修复从库上无主键、无索引表——这类表的每一行 UPDATE 都触发全表扫描，严重拖慢单个 worker，进而阻塞整个 pipeline
- 监控
Seconds_Behind_Master不降但Retrieved_Gtid_Set和Executed_Gtid_Set差距扩大，大概率是逻辑依赖卡住，此时应检查主库近期是否有大事务或 DDL
