MySQL主备切换后并行复制配置解决SQL延迟

# MySQL 主备切换后延迟飙升？别急着调 `sla ve_parallel_workers`，先看这 4 个关键点 > 并行复制未提速的根本原因，往往是主库写入串行或事务冲突导致从库无法并发执行；需检查并行模式、WRITESET 降级条件、GTID 对齐及主库写法优化。

为什么设置了 `sla ve_parallel_workers` 却没提速？

常见现象是：主备切换后，从库的 `Seconds_Behind_Master` 持续上涨，即使开了并行复制，延迟也没明显下降。根本原因不是参数没生效，而是 MySQL 的并行复制机制（基于 `LOGICAL_CLOCK` 或 `WRITESET`）默认只对「能保证事务间无冲突」的 SQL 才真正并发执行。如果主库写入模式高度串行（比如单线程压测、频繁更新同一张表的同一行），从库照样只能串行回放。 实操建议：

• 先确认当前并行模式：SHOW VARIABLES LIKE 'sla ve_parallel_type'; —— 推荐设为 LOGICAL_CLOCK（MySQL 5.7+ 默认）或更优的 WRITESET（MySQL 8.0.19+）。
• 检查是否启用了 `sla ve_preserve_commit_order=ON`（尤其在 WRITESET 模式下必须开，否则可能丢序）。
• `sla ve_parallel_workers` 值不是越大越好；设为 4~8 通常比设成 32 更稳，过多线程反而因调度开销和锁竞争拖慢整体吞吐。

`WRITESET` 模式下哪些操作会退化为串行？

`WRITESET` 依赖主库 binlog 中记录的「写集合」（即事务修改的唯一键哈希），来判断事务是否可并行。但以下情况会导致写集合为空或失效，从而强制降级为单线程回放：

• 事务中含 DDL（如 ALTER TABLE）—— 整个事务被标记为不可并行。
• 使用了非事务引擎（如 MyISAM）—— 无 row format binlog，无法提取 writeset。
• 更新语句未命中唯一索引（例如 UPDATE t SET a=1 WHERE b=2，而 b 不是唯一键）—— 写集合无法精确到行，保守起见串行处理。
• 主库 `binlog_row_image=MINIMAL` 且事务含外键或触发器 —— 可能导致 writeset 计算不全。

验证方式：SHOW SLA VE STATUS\G 中观察 Sla ve_SQL_Running_State 是否长期卡在 Waiting for preceding transaction to commit，这是 writeset 等待依赖的典型信号。

主备切换后延迟突增，光调参数没用，得看 binlog 位置和 GTID

切换本身不产生延迟，但切换后从库重连新主时，若没正确对齐位点或 GTID set，会从错误位置开始拉取 binlog，导致大量重复或跳过事件，继而引发 SQL 线程反复报错、重试、甚至卡死。此时调 `sla ve_parallel_workers` 完全无效。 关键检查点：

• 切换前确认新主库的 `gtid_executed` 包含旧从库已执行的全部 GTID（用 SELECT GTID_SUBSET(@old_sla ve_gtid, @new_master_gtid); 验证）。
• 切换后立即查 `SHOW SLA VE STATUS\G` 中的 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否连续、无缺口。
• 若发现 Seconds_Behind_Master 为 0 但 Sla ve_SQL_Running_State 是 Reading event from the relay log，说明 relay log 里有损坏或格式不兼容的 event（常见于跨版本切换）。

真正影响并行效率的其实是主库写法

再好的从库配置也救不了主库的串行写。比如一个业务逻辑把 100 条订单更新塞进同一个事务，或者所有写请求都打到 `user_id = 123` 这一行，那无论 `sla ve_parallel_workers` 设多大，从库也只能排队执行。 优化方向更该落在主库侧：

• 拆大事务：避免单事务更新超过 1000 行；用 COMMIT 分段提交。
• 分散热点：给高频更新字段加随机后缀（如分桶）、或改用自增 ID + 异步聚合，减少单行/单页争用。
• 确认主库 `binlog_transaction_dependency_tracking` 设为 `WRITESET`（而非默认的 COMMIT_ORDER），否则从库无法利用 writeset 并行。

最常被忽略的一点：MySQL 8.0 的 `WRITESET_SESSION` 模式能进一步按 session 隔离并行域，但要求应用层明确用 `SET SESSION binlog_transaction_dependency_tracking = WRITESET_SESSION;`，否则仍走全局 writeset。