MySQL 复制延迟怎样按并行工作线程分析

MySQL 复制延迟升高时，先别急着把并行工作线程数量调大。真正需要回答的是：副本有没有启用多线程应用、哪些工作线程在拖尾、协调线程是否已经分发不动，以及延迟是否由事务重试或单个大事务造成。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/replication-threads-monitor-worker.html

实用的分析顺序是：先看通道级状态，再确认 replica_parallel_workers，最后按 WORKER_ID 展开工作线程。只看 SHOW REPLICA STATUS 的一个延迟字段，很容易把“所有线程都忙”和“一个线程拖尾”混为一谈。

并行复制能力到底是什么

MySQL 8.4 把多线程副本的应用过程拆成协调线程和多个工作线程。协调线程从中继日志读取事务并分发，工作线程负责具体应用；因此“并行工作线程多”不等于“所有事务都能同时执行”。事务之间的依赖、提交顺序和冲突仍会限制并行度。

先在副本上确认关键变量，避免把配置文件里的预期值当成运行时事实：

-- 查看当前副本的并行应用配置
SHOW VARIABLES
WHERE Variable_name IN ('replica_parallel_workers', 'replica_parallel_type');

-- 查看默认通道的整体状态；多通道环境要逐个核对 CHANNEL_NAME
SHOW REPLICA STATUS\G

replica_parallel_workers 是动态的整数变量，MySQL 8.4 的默认值为 4，取值范围是 0 到 1024；但默认值不代表当前负载一定适合四个线程。replica_parallel_type 还涉及事务如何被分组调度，不能只改一个变量就推断延迟会下降。

先把通道级延迟和应用状态分开

SHOW REPLICA STATUS 适合快速确认连接是否正常、复制线程是否运行，以及当前通道是否存在明显延迟。但它更像总览，无法完整呈现每一个工作线程的最后事务、错误和时间差。

可以先保存一份通道级观察结果，再用 Performance Schema 继续下钻：

-- 先确认连接线程和应用线程是否都在运行
SHOW REPLICA STATUS\G

-- 查看每个通道的应用服务状态和事务重试总数
SELECT CHANNEL_NAME,
       SERVICE_STATE,
       COUNT_TRANSACTIONS_RETRIES,
       REMAINING_DELAY
FROM performance_schema.replication_applier_status
ORDER BY CHANNEL_NAME;

如果连接线程是运行状态而应用线程停了，先处理应用错误；如果应用线程在运行但延迟持续增加，再继续查看工作线程。COUNT_TRANSACTIONS_RETRIES 变大时，延迟可能来自反复重试，而不是简单的工作线程数量不足。

按工作线程判断是谁在拖尾

多线程副本的核心观察表是 performance_schema.replication_applier_status_by_worker。它按通道和工作线程提供状态；表中每一行代表一个工作线程，适合用聚合查询先看分布，再选出异常线程看详情。

-- 先按通道汇总工作线程的状态和错误数量
SELECT CHANNEL_NAME,
       COUNT(*) AS worker_count,
       SUM(SERVICE_STATE = 'ON') AS active_or_idle_workers,
       SUM(LAST_ERROR_NUMBER  0) AS workers_with_error,
       MAX(LAST_ERROR_TIMESTAMP) AS latest_error_time
FROM performance_schema.replication_applier_status_by_worker
GROUP BY CHANNEL_NAME;

-- 再查看每个工作线程最近一次事务与错误信息
SELECT CHANNEL_NAME,
       WORKER_ID,
       THREAD_ID,
       SERVICE_STATE,
       LAST_SEEN_TRANSACTION,
       LAST_ERROR_NUMBER,
       LAST_ERROR_MESSAGE,
       LAST_ERROR_TIMESTAMP,
       APPLYING_TRANSACTION,
       APPLYING_TRANSACTION_START_APPLY_TIMESTAMP
FROM performance_schema.replication_applier_status_by_worker
ORDER BY CHANNEL_NAME, WORKER_ID;

这里要看的是“分布”，而不是某个瞬间的绝对值：

把协调线程和工作线程放在同一条链路上

如果工作线程看起来没有错误，但延迟仍在扩大，继续看协调线程：

-- 查看协调线程当前处理和最近一次分发的事务
SELECT CHANNEL_NAME,
       SERVICE_STATE,
       PROCESSING_TRANSACTION,
       PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,
       PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP,
       LAST_ERROR_NUMBER,
       LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_coordinator;

-- 用整体应用状态补充重试次数和通道级信息
SELECT CHANNEL_NAME,
       SERVICE_STATE,
       COUNT_TRANSACTIONS_RETRIES
FROM performance_schema.replication_applier_status;

协调线程正在处理但工作线程大多空闲，通常应先怀疑可并行化的事务不足、依赖关系或分发受限；协调线程和工作线程都忙，则更像副本整体处理能力不足。判断要基于一段观察窗口，不能依据一次查询瞬间下结论。

增加工作线程前要留出回退路径

增加 replica_parallel_workers 可能带来更多调度和资源竞争，且不会消除事务依赖。生产调整前建议记录以下基线：

• 通道级延迟、应用线程状态和重试总数。
• 每个工作线程的最后事务、错误字段和应用时间。
• 副本 CPU、磁盘写入、磁盘延迟和事务大小分布。
• 调整前后的固定观察窗口，以及恢复原值的命令。

-- 示例：先记录原值，再在维护窗口内调整并保留回退命令
SELECT @@GLOBAL.replica_parallel_workers AS old_worker_count;

-- 仅示例，实际值应依据基线和资源余量选择
SET GLOBAL replica_parallel_workers = 8;

-- 出现资源争用或延迟恶化时，回退到记录的原值
SET GLOBAL replica_parallel_workers = 4;

调整后仍要重新执行工作线程查询。若延迟没有改善但线程更忙，问题可能在事务依赖、单个大事务或存储层，而不是并行度。若出现新的工作线程错误，应优先回滚变更并处理错误。

常见问题

为什么 replication_applier_status_by_worker 没有行？

先看 replica_parallel_workers 是否大于 0，并确认已经启动复制；单线程模式不会按多工作线程方式填充该表。

只看 Seconds_Behind_Source 可以吗？

不建议。它适合做快速信号，但不能告诉你哪个工作线程拖尾、是否有重试，也不能解释事务依赖。应和通道状态及 Performance Schema 表一起看。

工作线程数量越多，延迟一定越低吗？

不一定。事务依赖、提交顺序、单个大事务、磁盘和锁竞争都可能成为新的瓶颈。

为什么 SHOW REPLICA STATUS 没有显示所有工作线程错误？

多线程副本应查看 replication_applier_status_by_worker。通道级输出更适合总览，逐线程表才能保留每个线程的错误信息。

分析 MySQL 复制延迟时，把“副本是否多线程”“通道是否运行”“工作线程是否均衡”“是否存在错误或重试”四个问题分开，通常比直接调大并行线程更快找到方向。先保存基线，再做小步调整，最后用同一组查询比较结果。