slave_parallel_workers本身不提升并发，真正决定并行效果的是slave_parallel_type、主库binlog生成方式及元数据存储机制；仅调大该值而忽略配套配置，90%场景下延迟反而恶化。
slave_parallel_workers 本身不能“提升并发”——它只是 worker 线程的数量占位符，设了不等于跑起来，更不等于变快。真正决定是否并行、能并行多少的，是 slave_parallel_type 的取值、主库 binlog 生成方式、以及元数据存储机制。单纯调大这个值，90% 的线上环境只会看到 Seconds_Behind_Master 越来越糟。
为什么 slave_parallel_workers 设了但 SHOW SLAVE STATUS\G 仍显示单线程？
这是最常被忽略的前提断层：MySQL 5.7 的并行复制不是“参数一开就自动并行”，而是依赖 coordinator + worker 架构启动，而该架构仅在特定条件下激活。
-
slave_parallel_workers = 0：纯单线程 SQL 线程回放，无 coordinator，无 worker -
slave_parallel_workers = 1：coordinator 存在，但只配一个 worker，事务仍串行；实测比 = 0 慢约 20%（多一层调度开销） -
slave_parallel_workers > 1且slave_parallel_type != 'LOGICAL_CLOCK'：参数被静默忽略，降级为单线程
常见错误现象：
-
Slave_SQL_Running_State长期卡在Reading event from the relay log -
performance_schema.replication_applier_status_by_worker只返回 1 行，WORKER_ID = 1 -
SHOW PROCESSLIST里看不到Worker 2、Worker 3等线程
根本原因几乎总是：slave_parallel_type 还是默认的 'DATABASE'，而你的业务写入集中在单个库（比如 app_db），此时无论设多少 workers，都只有 1 个在干活。
必须同步改的三个关键参数：slave_parallel_type、master_info_repository、slave_preserve_commit_order
slave_parallel_workers 要生效，这三项必须按顺序、一次性配齐，缺一不可：
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD;（IO 线程可不停） - 改并行策略：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';（注意大小写，不能写logical_clock或Logical_Clock） - 改元数据存储：
SET GLOBAL master_info_repository = 'TABLE';和SET GLOBAL relay_log_info_repository = 'TABLE';（若保持FILE，多个 worker 会争抢写master.info，导致元数据错乱甚至复制中断） - 强制保序：
SET GLOBAL slave_preserve_commit_order = ON;（否则跨 worker 提交可能破坏事务可见性，引发主从不一致） - 最后启动：
START SLAVE SQL_THREAD;
验证是否成功：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
SELECT * FROM performance_schema.replication_applier_status_by_worker;应返回多条非空记录，WORKER_ID > 0 -
SHOW SLAVE STATUS\G中Slave_SQL_Running_State应出现Waiting for an event from Coordinator
主库配置不匹配，slave_parallel_workers 就是摆设
LOGICAL_CLOCK 模式依赖主库 binlog 中的 last_committed 和 sequence_number 字段分组事务。这些字段只在以下条件下生成：
-
binlog_format必须为ROW（MIXED在含NOW()、UUID()等非确定函数时会退化为STATEMENT，丢失组提交信息） -
binlog_order_commits建议显式设为ON（MySQL 5.7 默认开启，但线上常被覆盖） - 若主库是 MySQL 5.7.20+，可设
binlog_transaction_dependency_tracking = WRITESET（比默认COMMIT_ORDER更细粒度，支持跨表并行）
检查命令：
SELECT @@binlog_format, @@binlog_order_commits, @@binlog_transaction_dependency_tracking;
若不满足，仅从库调参毫无意义——relay log 里压根没有可用于分组的时间戳，worker 拿不到并行依据，只能退回单线程。
slave_parallel_workers 设多少才合理？
不是越多越好，4～8 是多数 OLTP 场景的安全起点：
- CPU 核心数 ≤ 8：建议设为 4 或 6
- CPU 核心数 ≥ 16：可设为 8～12，再高易引发 mutex 争用和上下文切换损耗
- relay log 所在磁盘是 SATA SSD 或 HDD：worker 超过 4 后吞吐基本不涨，I/O 成瓶颈
- 观察
Replica_queue_size（SHOW SLAVE STATUS输出项）：若长期 > 1000，说明 relay log 积压严重，问题在 IO 线程或网络，不是 SQL 并发度
特别注意：如果主库写入集中在少数几张大表（比如日志表无主键），slave_parallel_workers 再大也没用——并行线程会因 Error_code: 1032（找不到行）频繁失败回退。先确保所有表有主键或唯一索引，才是启用并行的前提。
