MySQL 复制延迟怎样区分 IO 线程和 SQL 线程

MySQL 复制出现延迟时，先不要只盯着 Seconds_Behind_Source。真正有用的第一步是把副本上的复制链路拆成两段：IO（receiver）线程负责从源库读取 binary log 并写入 relay log，SQL（applier）线程负责读取 relay log 并执行事务。前者落后，问题通常在连接、网络或源库发送；后者落后，问题通常在副本执行、锁等待、资源不足或 SQL 应用错误。

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

判断复制延迟的核心是同时比较 Replica_IO_Running、Replica_SQL_Running、读取位点、执行位点和两类错误。IO 正常但 SQL 落后，优先查 relay log 堆积与应用能力；IO 不正常，则先查连接和接收错误。

先用一条状态命令看清两条线程

在副本执行下面的查询。\G 只是让长字段按纵向显示，便于把同一时刻的状态放在一起比较。

-- 在副本上读取当前复制通道状态，长字段用纵向格式展示
SHOW REPLICA STATUS\G

先记录这几组字段：

比较读取位点和执行位点，判断延迟堆在哪里

IO 线程读取源库事件后，会把内容写进副本的 relay log；SQL 线程再从 relay log 读取并执行。因此可以把下面两组位点理解为“已经接收到哪里”和“已经应用到哪里”。

-- 只挑出排障时最关键的接收、执行和堆积字段
SHOW REPLICA STATUS\G

-- 兼容最常用的单通道排查方式；真实字段以 SHOW 输出为准
-- Read_Source_Log_Pos：IO 线程读取到的源库位点
-- Exec_Source_Log_Pos：SQL 线程执行到的源库位点

生产排查通常以 SHOW REPLICA STATUS 为主，因为它同时给出源日志位点、relay log 空间、线程运行状态和错误字段。对同一通道连续观察时，若 Read_Source_Log_Pos 持续前进而 Exec_Source_Log_Pos 长时间不动，说明接收在继续、应用端没有跟上，重点转向 SQL 线程。若读取位点本身不前进，先看 IO 状态和 Last_IO_Error。

IO 线程慢，和 SQL 线程慢分别怎么处理

可以按下面的分流方式缩小范围：

• IO 为 No 或 Connecting：查看 Last_IO_Error 与 Last_IO_Error_Timestamp，优先排查源库地址、复制账号、TLS、网络连通性和源端是否仍保留需要读取的 binary log。此时 SQL 线程即使是 Yes，也可能只是把已有 relay log 消化完。
• IO 为 Yes，SQL 为 No：先读 Last_SQL_Error，不要直接跳过事务。常见原因包括副本表结构不一致、唯一键冲突、权限问题或执行资源不足；应先确认错误上下文，再选择修复数据、结构或配置。
• IO 和 SQL 都为 Yes，但位点差距增大：比较读取位点、执行位点和 Relay_Log_Space。差距持续扩大，通常说明副本应用速度低于接收速度，需要继续查慢事务、锁等待、磁盘与并行应用配置。
• 两者都是 Yes，位点接近且 relay log 不增长：这更像暂时没有需要应用的事件，不应仅凭某一次采样宣布“延迟已经恢复”。

为什么 Seconds_Behind_Source 为 0 仍不能直接下结论

Seconds_Behind_Source 是有条件的延迟估计：副本正在处理事件时，它大致反映副本当前时间与源库事件原始时间戳的差值；没有事件正在处理时可能显示 0。官方文档还特别说明，网络较慢时，IO 线程本身可能已经落后源库，但 SQL 线程只是追上了当前收到的 relay log，结果仍可能是 0。

因此，排查时建议至少连续采样两三次，并把秒数与线程状态、位点和错误一起记录：

-- 每次采样保留同一组字段，避免只看瞬时秒数
SHOW REPLICA STATUS\G

-- 关注这几个字段的变化：
-- Replica_IO_Running / Replica_SQL_Running
-- Read_Source_Log_Pos / Exec_Source_Log_Pos
-- Relay_Log_Space / Seconds_Behind_Source
-- Last_IO_Error / Last_SQL_Error

还有两个边界需要记住：应用线程没有运行时，MySQL 8.4 中延迟秒数可能是 NULL；多线程副本中，这个数值基于执行位点，并不一定代表最近提交事务的精确位置。更稳妥的结论是：Seconds_Behind_Source 负责提示趋势，线程状态和位点负责解释原因。

常见追问

IO 线程是 Yes，SQL 线程也是 Yes，为什么复制还会有延迟？

线程“在运行”不等于处理速度足够。继续看读取位点是否持续领先执行位点，以及 Relay_Log_Space 是否增加；如果差距扩大，再查慢事务、锁等待、磁盘和应用并发能力。

可以只看 Last_SQL_Error 判断 SQL 线程问题吗？

不可以。空错误字段只表示当前没有记录最近一次停止错误，不能证明 SQL 线程没有积压；需要同时观察 Replica_SQL_Running、执行位点和 relay log 空间。

MySQL 8.4 还要看旧的 Slave_IO_Running 吗？

新命名是 Replica_IO_Running 和 Replica_SQL_Running。排查旧版本或旧脚本时可能遇到旧字段名，但文章中的判断逻辑仍是区分 receiver 与 applier 两条线程。

把复制延迟拆成“接收慢”与“应用慢”，再用读取位点、执行位点和两类错误互相印证，通常比盯着一个秒数更快定位。修复动作也应跟着归因走：IO 问题先处理连接链路，SQL 问题先处理执行错误和副本负载。