MySQL 8.4 复制延迟怎么拆分：事务大小、并行回放与队列指标核对

线上主库写入量没有明显变化，副本却从几秒延迟慢慢拉到几分钟，第一反应往往是把 replica_parallel_workers 调大。这个动作有时有效，但也可能掩盖真正的问题：接收线程没有跟上、单个大事务卡住一个 worker，或者协调器已经把可并行的工作分完，剩下的是无法拆开的提交边界。

排查 MySQL 8.4 复制延迟，先把“延迟”拆成接收、回放、worker 和提交四段，再决定是否调整并行度；只看一个总秒数，不足以说明瓶颈在哪里。

先把复制延迟拆成四段

一个副本从源端追赶数据，至少经过四个阶段：源端产生二进制日志，副本接收并写入 relay log，协调器把事务交给 applier worker，最后事务完成提交并推进执行位置。每一段都可能成为瓶颈。

因此，看到 Seconds_Behind_Source（旧版本常见名称是 Seconds_Behind_Master）上升时，先不要把它当成精确的排队时长。它更像一个需要结合线程状态解释的信号。MySQL 8.4 文档也提醒，副本应用线程未运行、或接收线程未运行且 relay log 已经消耗完时，这个字段可能是 NULL。

第一步：确认是接收慢，还是回放慢

先保存现场，不要边看边重启副本：

SHOW REPLICA STATUS\G

重点看接收线程和应用线程是否都在运行、源日志位置与副本执行位置是否持续变化，以及 relay log 是否不断堆积。若接收位置本身就追不上源端，网络、源端日志读取或接收线程是优先方向；若接收已经领先而执行位置落后，才进入回放侧。

SHOW REPLICA STATUS 是非阻塞查询，适合采样，但它并不保证你看到的是停止操作完成后的最终状态。线上记录时至少连续采样两次，间隔由监控采样周期决定，不要用一次结果下结论。

第二步：看多线程回放是否真的在工作

确认副本启用了多线程后，再查 Performance Schema：

SELECT CHANNEL_NAME,
       WORKER_ID,
       SERVICE_STATE,
       APPLYING_TRANSACTION,
       LAST_APPLIED_TRANSACTION,
       LAST_ERROR_NUMBER,
       LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_worker
WHERE CHANNEL_NAME = ''\G

这个表按 worker 展示事务应用状态；单线程副本也会有对应的应用线程记录，多线程副本则可以观察每个 worker。若只有一个 worker 长时间处理同一事务，其他 worker 空闲，常见原因是大事务、热点行冲突或事务之间存在无法并行的依赖。

这里别急着把空闲 worker 当成故障。并行回放的前提是事务之间可以安全交错；一批事务如果都触碰同一张热点表甚至同一组行，增加线程只会增加调度和锁竞争。

第三步：用事务大小和队列增长解释现场

如果接收端持续领先、worker 表显示应用端仍在处理，而 relay log 继续增长，下一步应把“谁在拖慢回放”落到事务上。可以从源端慢事务、批量更新、单次导入量和提交时间入手，再对照副本上的应用事务。

典型的判断顺序如下：

如果需要长期观察，可把 worker 状态、relay log 体量、事务应用耗时和错误计数按同一个时间轴落盘。单独看一次 worker 快照，无法区分“刚接到任务”和“已经卡了很久”。

调整并行度前，先做一个可回退的变更

replica_parallel_workers 决定副本用于执行复制事务的 applier worker 数量。它不是越大越好：CPU、磁盘、锁冲突和事务依赖都会限制收益。调参前记录当前值、延迟曲线、磁盘写入和 worker 状态，选择一个小步幅变更。

SHOW VARIABLES LIKE 'replica_parallel_workers';
SHOW STATUS LIKE 'Innodb_row_lock%';

调整后继续观察同一组指标。如果 worker 更忙但延迟没有下降，甚至锁等待和磁盘压力上升，就回到原值，并把问题转向大事务拆分、热点写入治理或副本硬件容量。不要在延迟峰值期间连续修改多个参数，否则无法知道哪一个动作改变了结果。

错误、回滚和告警要分开处理

若 Last_SQL_Error 不为空，先保留错误文本、时间戳、通道名和 worker 行信息。多线程副本中，协调器字段看到的错误不一定包含所有 worker 的失败细节，官方建议结合 replication_applier_status_by_worker 或副本错误日志继续定位。

告警可以按两类设计：延迟持续超过业务阈值的趋势告警，以及接收线程、应用线程或 worker 错误的状态告警。恢复后不要只关闭告警，还要确认 relay 队列开始下降、执行位置继续推进，且没有新的 worker 错误。

常见问题

只把 replica_parallel_workers 调大就能解决延迟吗？

不能。事务依赖、热点锁和大事务会限制并行收益；如果接收端、磁盘或错误重试才是瓶颈，扩 worker 反而会增加压力。

Seconds_Behind_Source 是 NULL 代表复制彻底坏了吗？

不一定。应用线程未运行、接收线程未运行且 relay log 已经耗尽等状态都可能让它为 NULL，需要结合线程状态和位置字段判断。

为什么大多数 worker 空闲，只有一个很忙？

常见解释是当前事务很大，或事务之间存在热点锁与提交依赖。先查事务边界和涉及对象，不要把空闲直接判断为线程故障。

把一次延迟告警变成可复用的判断路径

稳定的处理顺序是：先保存 SHOW REPLICA STATUS 现场，再确认接收和回放的方向，随后看 worker 级别状态，最后才评估并行度和事务拆分。这样做的价值不在于每次都能立刻追平，而是能把“副本慢了”变成有证据的判断：是链路没进来、回放吞吐不够，还是一笔事务把可并行空间锁住了。