MySQL 5.7中slave_parallel_workers调大无效的根本原因是未启用LOGICAL_CLOCK模式：必须同时满足主库binlog_format=ROW、从库slave_parallel_type='LOGICAL_CLOCK'且设为TABLE元数据存储，并执行STOP/START SLAVE重启，缺一不可。
MySQL 5.7 的 slave_parallel_workers 不是“调大就加速”的开关，它必须和 slave_parallel_type = 'LOGICAL_CLOCK' 配合生效，否则设成 16 也只跑 1 个线程。
为什么调了 slave_parallel_workers 积压还是不降？
常见错误现象是 Seconds_Behind_Master 持续上涨，但 SHOW PROCESSLIST 里只看到 SQL Thread，没有 Worker N 线程；或者 SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长期卡在 Reading event from the relay log —— 这说明并行根本没启动。
-
slave_parallel_workers > 0但slave_parallel_type仍是'DATABASE'（默认值）：跨库写少时等同于单线程 - 主库
binlog_format是MIXED或STATEMENT：LOGICAL_CLOCK依赖的last_committed字段不会生成 - 从库元数据仍用
FILE：必须设为TABLE，否则START SLAVE会静默降级 - 没执行
STOP SLAVE就直接改slave_parallel_type：该变量不支持热更新，修改无效
必须停库执行的三步配置顺序
截至 2026 年 10 月，slave_parallel_type 仍无法在线修改。跳过任一环节，START SLAVE 可能失败或退化为单线程：
- 主库先确认：
SET GLOBAL binlog_format = 'ROW';，并检查binlog_row_image = 'FULL' - 从库执行：
STOP SLAVE;→SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';→SET GLOBAL slave_parallel_workers = 4;（建议从 4 起步，不超过 CPU 核心数） - 从库同步设置：
SET GLOBAL master_info_repository = 'TABLE';、SET GLOBAL relay_log_info_repository = 'TABLE';、SET GLOBAL relay_log_recovery = ON;
如何验证并行是否真在跑？
不能只看参数值，得查运行态：
- 执行
SELECT * FROM performance_schema.replication_applier_status_by_worker;：应看到多行（WORKER_ID≥ 2），且PROCESS_ID非空、LAST_APPLIED_TRANSACTION值各不相同 - 执行
SHOW VARIABLES LIKE 'slave_parallel_type';：返回值必须是'LOGICAL_CLOCK'，不是'DATABASE' - 执行
SHOW PROCESSLIST;：应出现多个system user开头的Worker线程，状态为Waiting for an event from Coordinator或Executing event - 若
Slave_SQL_Running_State显示Waiting for dependent transaction to commit：说明事务间有逻辑依赖未解开，需检查主库是否启用组提交、是否存在跨库 DML 或无主键表
积压清零后 worker 自动缩容是正常行为
slave_parallel_workers 是最大并发数，不是常驻数。当 relay log 积压清空、事务流变稀疏时，MySQL 会自动减少活跃 worker 数量以节省资源——这不是故障，也不需要干预。
真正容易被忽略的是：即使所有配置都对，只要有一张表缺主键，Error_code: 1032 就会让整个并行回放中断；而 Seconds_Behind_Master = 0 并不代表数据已可见，它不统计 worker 队列里的待执行事务。
