MySQL 复制延迟区分线程 怎样处理

MySQL 复制延迟要先分清接收侧和应用侧：接收线程负责从源端取得事件，应用侧负责在副本执行；并行复制还要分别看协调线程与工作线程。不能只凭 Seconds_Behind_Source，或看到 IO、SQL 都是 Yes，就直接认定网络或磁盘故障。正确做法是按通道保留各线程状态、错误和事务进度，再决定调查方向。

下面组织一个小型“只读复制状态报告”：输入副本实例和通道名，输出接收、协调、工作线程三组记录，以及一次后续采样的变化。范围限定 MySQL 8.4 传统异步复制，不覆盖 Group Replication 的完整诊断。文中的 SQL 未在本地数据库运行，不附虚构现场数据。官方入口：https://dev.mysql.com/doc/refman/8.4/en/show-replica-status.html。

先定义报告里的三个职责边界

接收侧从源端二进制日志接收事件并写入 relay log；并行应用侧由协调线程分配工作，工作线程执行事务。报告按 CHANNEL_NAME 组织，不把不同源、不同通道的错误和进度混在一起。

静态结构中，源端日志与接收线程有关，接收线程与 relay log 有关，协调线程与 relay log、工作线程有关，工作线程负责副本数据的应用。图中的关系线只表达职责依赖，不表示这些组件总在某个固定顺序串行执行。

本项目只做观察与分类，不自动重启复制、跳过事务、重置元数据或改并行度。延迟本身不是足够的修改依据，数据一致性错误尤其不能用“先跳过去”处理。

准备通道名与一次可比较的采样

-- 在目标副本连接中记录实例和采样时间；默认通道名为空字符串。
SELECT NOW(6) AS sampled_at, @@server_uuid AS replica_uuid,
       @@version AS mysql_version;
SET @channel_name = '';

-- 查看当前连接对应副本的通道总览，不修改复制状态。
SHOW REPLICA STATUS;

SET 在这里只设置当前连接的用户变量，不修改服务器复制配置。后续 SELECT 必须在同一连接执行；连接池切换连接时应重新设置变量，或改用驱动参数绑定通道名。SHOW 的多通道输出可能有多行，要选中与你的 CHANNEL_NAME 相同的那一行。

由管理员配置合适的监控权限；SHOW REPLICA STATUS 需要相应复制查看权限，Performance Schema 查询还取决于账号授权和实例配置。查询报权限错误应保留失败信息，不能把“没有读到状态”当作线程停止或健康。记录时不要把连接凭据、完整业务语句或内部地址公开。

每份报告至少保存实例 UUID、版本、采样时间、通道、查询是否成功。几组状态表不是同一个冻结快照，采集期间线程可能继续变化；需要在记录中保留这个限制。

接收、协调、工作线程分别采集

-- 接收侧：每个通道一行，错误字段必须与服务状态一起记录。
SELECT CHANNEL_NAME, THREAD_ID, SERVICE_STATE,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP,
       RECEIVED_TRANSACTION_SET
FROM performance_schema.replication_connection_status
WHERE CHANNEL_NAME = @channel_name;

-- 协调侧：并行复制中负责工作分配，不代表所有工作线程都无异常。
SELECT CHANNEL_NAME, THREAD_ID, SERVICE_STATE,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP
FROM performance_schema.replication_applier_status_by_coordinator
WHERE CHANNEL_NAME = @channel_name;

-- 工作线程逐行保留，不能只取一行或用 MAX 状态替代。
SELECT CHANNEL_NAME, WORKER_ID, THREAD_ID, SERVICE_STATE,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP,
       LAST_APPLIED_TRANSACTION, APPLYING_TRANSACTION,
       APPLYING_TRANSACTION_START_APPLY_TIMESTAMP
FROM performance_schema.replication_applier_status_by_worker
WHERE CHANNEL_NAME = @channel_name
ORDER BY WORKER_ID;

接收侧的 SERVICE_STATE 表示该接收服务的状态；结合 LAST_ERROR_NUMBER、MESSAGE 和 TIMESTAMP 看是否发生停止或连接问题。RECEIVED_TRANSACTION_SET 是收到的事务集合，在使用 GTID 的场景可作为进度线索，但其字符串长度不是积压事务数。

协调侧和工作侧的 ON 表示线程存在，可能正忙也可能空闲，并不等于“没有延迟”。协调线程的概览也不能替代每个工作线程的状态。逐个保留 WORKER_ID，才能发现只有某个工作线程持续处理同一事务的情况。

工作侧的 APPLYING_TRANSACTION 表示正在应用的 GTID，LAST_APPLIED_TRANSACTION 表示该工作线程最近应用的事务。前者为空不自动等于故障，可能是空闲；起始时间较早也不能直接断言死锁，还要看后续样本和等待信息。非 GTID 环境不能强行把这些事务字段当作完整进度依据。

用线程标识补充等待状态

-- THREAD_ID 与 Performance Schema 的 THREAD_ID 关联，不是连接 ID。
SELECT w.CHANNEL_NAME, w.WORKER_ID, w.THREAD_ID,
       w.SERVICE_STATE, w.APPLYING_TRANSACTION,
       t.PROCESSLIST_ID, t.PROCESSLIST_STATE
FROM performance_schema.replication_applier_status_by_worker AS w
LEFT JOIN performance_schema.threads AS t
  ON t.THREAD_ID = w.THREAD_ID
WHERE w.CHANNEL_NAME = @channel_name
ORDER BY w.WORKER_ID;

CHANNEL_NAME 把同一复制通道的记录归组，WORKER_ID 区分工作槽位，THREAD_ID 用于关联 performance_schema.threads。后者提供 PROCESSLIST_ID 和 PROCESSLIST_STATE；不要拿 PROCESSLIST_ID 直接连接 THREAD_ID。线程退出、监控可见性不足等情况都可能使关联列为空，所以这里使用 LEFT JOIN 保留原工作线程记录。

如果观察到锁等待状态，再结合受授权的锁等待信息调查阻塞者；若是提交顺序或依赖等待，应分析事务依赖，而不是把等待的工作线程数量当作 CPU 不足的证明。没有等待记录也不能排除磁盘、CPU 或采集配置问题。这份报告给出的是下一步方向，不是自动根因裁定。

整理成报告，再按证据选择处理范围

报告集成时保留原始状态与判断理由，而不是只生成一个“延迟正常”布尔值。可用已有采集器按业务允许的间隔重复查询，避免无限轮询和高频刷屏；每个样本保留独立时间。连接中断、字段不存在和权限不足要作为采集失败单独上报。

只有收集到对应证据后，才讨论具体处理：连接错误由负责源端或链路的人员修复；应用报错先解释事务和数据差异；工作线程等待先确认阻塞及影响。停止复制、终止连接、重建副本、调整并行配置都属于有影响的操作，不应由这份只读报告擅自执行。

恢复要看进度变化，不能只看一个零

Seconds_Behind_Source 是有条件的时间指示，不是所有事务从源提交到副本可见的完整度量。接收较慢、应用却已处理完当前 relay log 时，数值可能为零；NULL 也不能转换成零当作成功。源端和副本时钟变化、级联复制及并行提交都可能影响解读。

完成报告后，读者应能够回答：采的是哪个实例和通道，哪个线程存在异常，错误是什么时候出现的，事务或位置是否有持续进展，还有哪些信息缺失。恢复时要结合新的进度样本、错误时间与业务允许的读一致性确认，而不是看到旧错误文本仍在就断言仍失败，或只看到线程恢复 ON 就宣布所有数据一致。

SQL 线程是 Yes，为什么还落后？线程存在不等于处理能力足够，可能仍在执行、等待或按依赖提交；需要工作线程级观察。

某个工作线程空闲，是否该增加并行度？不能这样推断。空闲可能没有可分配任务，也可能任务之间有依赖；增加数量不保证单个大事务能被拆开。

没有查询结果就是没有复制吗？先核对通道过滤、实例身份、权限、配置及查询错误。报告应把“未配置”“未观察到”和“采集失败”区分开。

参考：接收状态表、协调线程状态表、工作线程状态表与 SHOW REPLICA STATUS 文档。