设了slave_parallel_workers却没提速，是因为主库binlog_format非ROW、未启用binlog_transaction_dependency_tracking=WRITESET、表无主键或唯一键、从库slave_preserve_commit_order=ON等条件不满足，导致MySQL自动降级为单线程回放。
设了 slave_parallel_workers 却没提速？不是参数没起作用，而是并行根本没触发——主从协同条件不满足时，MySQL 会自动降级为单线程回放。
为什么 slave_parallel_workers 设了等于白设
常见现象：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长期卡在 Waiting for preceding transaction to commit；performance_schema.replication_applier_status_by_worker 里多数 worker 状态是 Waiting for an event from Coordinator，且 WORKERS_PROCESSED 几乎不增长。
这不是配置没生效，是 MySQL 主动 fallback：它检测到事务间存在逻辑依赖，无法安全并行，就退回单线程。关键原因包括：
- 主库
binlog_format不是ROW（STATEMENT或MIXED下WRITESET直接失效） - 主库未启用
binlog_transaction_dependency_tracking = 'WRITESET'（默认COMMIT_ORDER，只按提交时间排序，同一 session 连续事务完全无法并行） - 被修改的表没有主键或非空唯一键（
WRITESET无法提取写集，自动退化） - 从库启用了
slave_preserve_commit_order = ON（MySQL 8.0.27+ 默认开启，强制按主库顺序提交，worker 实际串行等待）
主库必须配齐的四个硬性条件
并行复制不是从库单方面能决定的。主库配置才是源头，缺一不可：
-
binlog_format = ROW：必须是行格式，否则无写集可提取 -
binlog_row_image = FULL：MINIMAL会导致写集生成失败，PARTIAL已废弃 -
binlog_transaction_dependency_tracking = WRITESET：启用事务级依赖追踪，不是默认值 -
transaction_write_set_extraction = XXHASH64：推荐哈希算法，兼容性好、性能稳
验证命令（在主库执行）：
SELECT @@binlog_format, @@binlog_row_image,
@@binlog_transaction_dependency_tracking,
@@transaction_write_set_extraction;
预期返回应为：'ROW'、'FULL'、'WRITESET'、'XXHASH64'。
从库侧关键参数调优与避坑
主库达标后，从库才能真正利用多线程。重点不在盲目拉高 slave_parallel_workers，而在匹配实际负载和规避串行陷阱：
-
slave_parallel_type = LOGICAL_CLOCK：必须设为此值（不是DATABASE），才能基于WRITESET并行 -
slave_parallel_workers建议值 = CPU 核心数 × 1.5～2（如 16 核设 24），但超过 32 后收益递减，还可能争抢锁资源 -
slave_preserve_commit_order = OFF：显式关闭（尤其 8.0.27+ 版本），否则即使事务可并行，也会被强制串行提交 -
relay_log_recovery = ON：确保崩溃重启后 relay log 不损坏，避免 coordinator 分发异常
生效需重启复制：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 24; SET GLOBAL slave_preserve_commit_order = OFF; START SLAVE;
如何确认并行是否真正在跑
别只看参数，要看运行态指标：
- 查
SHOW PROCESSLIST：应看到多个Slave_worker线程处于Executing SQL或Waiting for an event from Coordinator，而非全卡在等待 - 查
performance_schema.replication_applier_status_by_coordinator\G：关注WORKERS_WAITING和WORKERS_PROCESSED的差值；若WORKERS_PROCESSED持续增长且远大于 0，说明分发正常 - 查
Seconds_Behind_Master是否稳定收敛：持续下降或波动收窄，才是有效并行；若长期 > 0 且抖动剧烈，大概率仍有大事务或无主键表在拖后腿
最易被忽略的一点：即使所有参数都对，只要有一张表没主键、或某次大事务跨了 10 万行更新，整个并行流水线就会被阻塞。所以优化不能只调参，得配合 pt-deadlock-logger 和慢日志分析，把“破坏者”揪出来。
