调高slave_parallel_workers积压不降，因并行复制需ROW格式+LOGICAL_CLOCK/COMMIT_ORDER模式；DATABASE模式下跨库少则无效；依赖未解时会卡在“Waiting for dependent transaction”；需检查配置、合理设值（建议4起调）、动态调整需STOP/START SQL线程；slave_preserve_commit_order=ON保一致但限并发，WRITESET启用可关；积压清零后自动缩容属正常自适应行为。
为什么 slave_parallel_workers 调高了，积压还是不降？
因为并行复制不是开个开关就自动加速——它依赖 binlog_format=ROW 且必须开启 slave_parallel_type=LOGICAL_CLOCK（MySQL 5.7+）或 COMMIT_ORDER（8.0+）。如果还在用 DATABASE 模式，哪怕设成 16，也只会在库级并发，跨库更新少时几乎无效。
常见错误现象：Seconds_Behind_Master 持续上涨，但 SHOW PROCESSLIST 里 Slave_SQL_Running_State 显示 “Waiting for dependent transaction to commit”，说明逻辑时钟依赖没解开。
- 检查当前配置：
SELECT @@slave_parallel_type, @@slave_parallel_workers, @@binlog_format; - 确认主库已启用
binlog_transaction_dependency_tracking=COMMIT_ORDER（8.0）或WRITESET（更优），否则从库无法生成合理依赖图 -
slave_parallel_workers设得过高反而增加调度开销，建议从 4 开始试，每轮 +2 观察Replica_Executed_General_Log和 CPU 使用率
如何安全地在线调整 slave_parallel_workers？
这个变量支持动态修改，但仅影响新启动的 worker 线程；已运行中的 SQL 线程不会被中断或重分配。真正生效要等当前 relay log 批次执行完、下一批次触发新 worker 启动。
使用场景：突发大事务写入后积压飙升，需快速响应，又不能停复制。
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD;（避免调整中出现状态错乱） - 再设值：
SET GLOBAL slave_parallel_workers = 8; - 重启 SQL 线程：
START SLAVE SQL_THREAD;—— 此时新 worker 才会拉起 - 观察
SHOW SLAVE STATUS\G中的Workers字段是否匹配，以及Seconds_Behind_Master是否进入下降通道
slave_preserve_commit_order=ON 到底要不要开？
它强制从库按主库提交顺序回放事务，是保证一致性（尤其涉及 GTID 或多线程写同一张表）的必要条件，但会显著限制并行度——所有依赖同一 commit_id 的事务必须串行执行。
性能影响明显：在高冲突业务（如订单+库存强关联）中，开它可能让并行退化为半串行；关它则可能在主库 crash 后导致从库数据短暂不一致（但 GTID 仍能保证最终一致）。
- 若业务能容忍极短时间（秒级）的中间态不一致，且主库
binlog_transaction_dependency_tracking=WRITESET已启用，可关：SET GLOBAL slave_preserve_commit_order = OFF; - 若用的是
COMMIT_ORDER模式，或主库未开启 writeset，则必须开，否则可能丢数据 - 注意：该变量不可动态关闭（MySQL 8.0.26 前），需重启从库；8.0.26+ 支持动态，但仍建议在低峰操作
积压清完后，为什么并行度又掉回 1？
这不是 bug，是 MySQL 的自适应行为：当 relay log 消费速度远超写入速度、积压接近 0 时，线程池会自动缩容，释放空闲 worker，避免资源浪费。但下次积压重现时，它不会立刻拉满，而是逐步扩容。
容易被忽略的地方：监控不能只看 Seconds_Behind_Master，要盯住 Slave_SQL_Running_State 和 Replica_SQL_Running_State 的具体状态，比如 “Reading event from the relay log” 表示 IO 线程在读，而 “Executing event” 才是 SQL 线程真正在跑；如果长期卡在前者，问题其实在网络或主库 dump 线程，跟并行度无关。
- 查实时 worker 数量：
SELECT * FROM performance_schema.replication_applier_status_by_worker; - 确认是否真在“缩容”：
SHOW STATUS LIKE 'Threads_connected';对比前后，排除连接数打满导致的假象 - 不要迷信固定数值——积压波动大的场景，更适合用
slave_parallel_workers=4~8+slave_preserve_commit_order=ON的稳态组合，而不是盲目堆 worker
