SQL slave_parallel_workers / slave_parallel_type 的并行复制模式选择

mysql 5.7 并行复制需匹配slave_parallel_type与业务写入模式：logical_clock模式下需binlog_format=row且innodb_flush_log_at_trx_commit=1才能生效；database模式仅按库并发，单库内仍串行，适合分库分表场景。

MySQL 5.7 并行复制：slave_parallel_workers 设多少才不白设

设了 slave_parallel_workers 却没提速，甚至主从延迟反而波动更大？大概率是没配对 slave_parallel_type，或者并行粒度和你的业务写入模式不匹配。

这个参数只在 slave_parallel_type = LOGICAL_CLOCK 下才真正起效；设成 DATABASE 时，slave_parallel_workers 实际只控制每个 DB 内的线程数（且 MySQL 5.7 中该模式下最多只用 2 个线程，设高了完全浪费）。

• slave_parallel_workers = 0：强制退化为单线程回放，别用，除非调试
• 生产建议从 4 或 8 起步，别盲目设到核数——线程太多会加剧 relay log 解析和事务冲突检测开销
• 观察 SHOW SLAVE STATUSG 中的 Seconds_Behind_Master 和 Slave_SQL_Running_State（是否频繁卡在 “Reading Event from the relay log”）
• 如果大量小事务按库隔离写入（比如分库分表中间件路由），slave_parallel_type = DATABASE 反而更稳，但别指望高并发

LOGICAL_CLOCK 模式下为什么还是串行回放

开了 slave_parallel_type = LOGICAL_CLOCK，也设了 slave_parallel_workers > 0，但 SHOW PROCESSLIST 里 SQL 线程始终只有一个在干活？问题往往出在主库的 binlog 格式或事务提交方式上。

LOGICAL_CLOCK 依赖主库生成的 last_committed 和 sequence_number 来判断事务可并行性。这两个字段只在 binlog_format = ROW 且事务使用 innodb_flush_log_at_trx_commit = 1（默认）时才可靠生成。如果主库用了 MIXED 或 STATEMENT，或开了组提交优化但压测时事务太轻量，last_committed 就容易全为 0，导致从库误判所有事务必须串行。

• 检查主库：select @@binlog_format, @@innodb_flush_log_at_trx_commit;
• 查 relay log 中事务标记：mysqlbinlog --base64-output=decode-rows -v relay-log-file | grep -A2 "last_committed"，看是否出现连续多个 last_committed=0
• 避免在主库执行超大 DML（如单事务更新百万行），它会阻塞组提交队列，拉低后续事务的并行潜力

DATABASE 模式 vs LOGICAL_CLOCK：怎么选不翻车

不是版本新就一定该用 LOGICAL_CLOCK。选错模式会导致复制延迟不降反升，甚至主从数据不一致风险上升。

slave_parallel_type = DATABASE 安全、简单、兼容性好，适合老系统或跨库关联强的场景（比如一个业务逻辑总在 order_db 和 user_db 间来回更新）；但它无法解决单库内高并发写入瓶颈。LOGICAL_CLOCK 理论吞吐更高，但要求主库写入具备“天然并行性”——即不同事务修改的数据行无锁竞争、不共享热点主键或二级索引。

• 如果主库有大量 UPDATE ... WHERE id = ?（id 是主键），且 id 分布均匀 → LOGICAL_CLOCK 更合适
• 如果主库常跑 UPDATE t SET status=1 WHERE create_time （范围更新+无主键条件）→ DATABASE 更稳，因为这类语句容易产生长事务和锁等待，LOGICAL_CLOCK 会把冲突事务错误并行，触发从库死锁重试
• 升级前务必在从库开启 log_slave_updates = ON，否则 GTID 复制链路可能断裂

并行复制生效后还要盯什么关键指标

看到 Seconds_Behind_Master 降了，不代表万事大吉。LOGICAL_CLOCK 模式下，SQL 线程数变多，但每个线程的负载不均、冲突重试、relay log 切换延迟都可能藏坑。

重点看 SHOW SLAVE STATUS 里的三个字段：Slave_SQL_Running_State 是否长期停在 “Waiting for dependent transaction to commit”；Retrieved_Gtid_Set 和 Executed_Gtid_Set 差距是否持续扩大；以及 Performance Schema 中 replication_applier_status_by_worker 表里各 worker 的 LAST_ERROR_MESSAGE 和 APPLYING_TRANSACTION 是否卡住。

• 如果某个 worker 长期空闲，其他 worker 一直忙，说明事务分配不均，可能是主库写入集中在某几张表（比如日志表）
• 频繁出现 “Deadlock found when trying to get lock” 错误，不是代码问题，而是并行回放时两个 worker 同时更新同一行 —— 这时得退回到 DATABASE 模式，或调整应用层写入节奏
• relay log 切换慢（Relay_Log_Space 持续增长）会拖累整体并行效率，确保 relay_log_space_limit 不设过小

LOGICAL_CLOCK 的并行能力不是开关一开就自动释放的，它高度依赖主库的事务组织方式和从库的资源调度精度。最常被忽略的是：没验证主库 binlog 的 last_committed 是否真实反映并行意图，就直接调高 slave_parallel_workers —— 结果只是多了几个等锁的空转线程。