MySQL 复制延迟升高时怎么区分 SQL 线程和 IO 线程

MySQL 复制延迟升高时，先不要只盯着 Seconds_Behind_Source。在 Replica 上执行 SHOW REPLICA STATUS\G，把问题拆成两个方向：IO（receiver）线程负责从 Source 接收二进制日志并写入 relay log，SQL（applier）线程负责读取 relay log 并应用事务。接收位置不再前进，优先查连接、认证和网络；接收正常但应用位置落后，才把重点放到 SQL 执行、锁等待或 Replica 吞吐上。

先用 SHOW REPLICA STATUS 拆开两个线程

在 Replica 执行下面的命令，并保留一前一后的两次输出。使用 \\G 是为了让字段按垂直方式展开，排障时不容易把 IO 与 SQL 字段看串。

-- 在 Replica 上查看当前复制通道的线程与位点
SHOW REPLICA STATUS\\G;

Replica_IO_Running: Yes 表示接收线程已启动并连接成功；Connecting 说明线程在运行但尚未连上 Source，No 则表示没有运行。Replica_SQL_Running 只回答应用线程是否启动，不能单独证明 relay log 已经追平。

再看两个状态文本：Replica_IO_State 常能说明接收线程是在等待 Source 事件还是连接异常，Replica_SQL_Running_State 能说明应用线程是否正在处理 relay log、等待锁，或已经读完当前 relay log。MySQL 手册也将这两个线程分别称为 replication I/O（receiver）和 replication SQL（applier）。

用位点差判断延迟卡在接收还是应用

确认线程名称后，再看位置。Read_Source_Log_Pos 是 IO 线程从当前 Source 二进制日志读到的位置，Exec_Source_Log_Pos 是 SQL 线程已经读完并执行的位置；Relay_Source_Log_File 表示最近一次由应用线程执行的事件来自哪个 Source 日志文件。

这里的“落后”应理解为同一复制通道内的相对关系，而不是简单相减不同日志文件的数字。多线程 Replica 还要注意，Seconds_Behind_Source 依据 Exec_Source_Log_Pos，不一定反映最近提交事务的最前位置。

Seconds_Behind_Source 在 Replica 正在处理事件时表示事件时间戳与 Replica 当前时间的差值；没有正在处理事件时可能为 0。网络较慢时，应用线程可能只是追平了慢速接收线程，秒数仍为 0，所以必须把线程状态、位置变化和 relay log 一起记录。

把异常落到 IO 和 SQL 错误字段

线程状态只能告诉你“哪里不正常”，错误字段才帮助缩小原因。Last_IO_Error 是最近一次导致 IO 线程停止的错误，常见排查方向包括 Source 地址不可达、复制账号认证失败、TLS 配置不匹配或读取日志失败。Last_SQL_Error 是最近一次导致 SQL 线程停止的错误，应该沿着表结构差异、权限、重复键、锁和事务语义继续查。

-- 只挑排障需要的字段，避免把整行输出复制进工单
SELECT CHANNEL_NAME,
       SERVICE_STATE,
       LAST_ERROR_NUMBER,
       LEFT(LAST_ERROR_MESSAGE, 200) AS LAST_ERROR_MESSAGE
FROM performance_schema.replication_connection_status;

-- 应用线程的协调器状态；多线程复制还应继续看 worker 表
SELECT CHANNEL_NAME,
       SERVICE_STATE,
       LAST_ERROR_NUMBER,
       LEFT(LAST_ERROR_MESSAGE, 200) AS LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_coordinator;

如果只想快速判断，仍以 SHOW REPLICA STATUS 为入口；Performance Schema 更适合在多通道或多线程复制中拆分连接端、协调器和 worker。MySQL 8.4 手册还提示，SQL 线程报告错误后到状态完全停下之间存在一个很小的窗口，因此一次看到错误号而状态仍为 Yes，不应立即判定字段矛盾。

常见问题

IO 线程和 SQL 线程都显示 Yes，为什么仍有复制延迟？

Yes 只说明线程已启动（IO 线程还表示已连接），不代表应用速度等于 Source 写入速度。对照读取位置、应用位置和 relay log 积压，才能判断是否有持续落后。

Seconds_Behind_Source 为 0 就一定没有延迟吗？

不一定。无事件、慢网络、时钟偏差和某些多线程应用场景都可能让它为 0 或不稳定，至少要结合位置变化和状态文本观察一个采样窗口。

应该先重启 Replica 还是先看错误字段？

先记录 Last_IO_Error、Last_SQL_Error、两个线程状态和位点，再决定是否重启。重启只能改变现场，不能修复账号、网络、表结构或 SQL 执行错误。

值班记录可以固定成四行：接收状态、应用状态、读取/执行位置、IO/SQL 最近错误。这样下一次延迟升高时，先能回答“数据有没有到 Replica”和“到了以后有没有被应用”，再选择网络、日志、锁或事务方向继续处理。