MySQL 主从延迟怎么定位：从 Seconds_Behind_Master 到复制队列逐层排查

线上读库延迟突然从几百毫秒涨到十几秒时，先别急着把只读流量切回主库。MySQL 主从延迟要先回答两个问题：副库 SQL 线程是真的落后，还是时间字段不可靠；落后以后，队列卡在取日志、执行事务，还是被某个大事务挡住。

排查顺序建议固定为：先看复制线程状态，再看 Relay Log 的接收与执行位置，最后用 Performance Schema 和事务信息定位具体阻塞。Seconds_Behind_Master 只能当线索，不能单独作为切流依据。

先确认延迟发生在哪一段

MySQL 复制至少有接收和应用两个阶段。IO 线程从主库拉取 binlog 写入 relay log，SQL 线程再读取 relay log 并执行。只看一个时间值，容易把“网络没收到日志”和“日志收到了但执行不完”混为一谈。

SHOW REPLICA STATUS\G
SHOW PROCESSLIST;

旧版本仍可能使用 SHOW SLAVE STATUS\G。结果里重点看 Replica_IO_Running、Replica_SQL_Running、Read_Source_Log_Pos、Exec_Source_Log_Pos、Relay_Log_Space 和两个线程的错误字段。不要只看 Seconds_Behind_Source 一行就下结论。

Seconds_Behind_Master 为什么会误导

这个值是根据复制线程看到的事件时间估算的，不是主库和副库所有数据的精确时间差。复制线程停止、主库事件时间异常、长事务没有提交时，它可能显示为 NULL；副库正在追赶时显示 0，也不代表所有队列已经清空。

更稳妥的做法是连续采样三次，把时间、读取位置、执行位置和 relay log 空间放在一起看。位置差持续扩大，才说明副库的应用速度确实低于主库产生速度。跨机房或时钟没有校准时，时间指标尤其只能用于趋势观察。

从复制位置判断队列是否正在变长

Read_Source_Log_Pos 代表副库 IO 线程已经读到的来源日志位置，Exec_Source_Log_Pos 代表 SQL 线程执行到的位置。两者差距不适合简单换算成“落后多少秒”，但在同一文件、同一采样窗口内，可以帮助判断队列是变长还是缩短。

-- 连续执行并记录每次输出中的文件和位置
SHOW REPLICA STATUS\G

-- 观察副库当前运行中的事务
SELECT THREAD_ID, EVENT_ID, STATE, TIMER_WAIT, SQL_TEXT
FROM performance_schema.events_statements_current
WHERE SQL_TEXT IS NOT NULL;

如果读取位置稳定向前，而执行位置几乎不动，问题在 SQL 线程或事务锁等待；如果两者都不动，先查 IO 线程和来源连接。这里别急着调参数，先证明队列卡点在哪一层。

定位是大事务、锁等待还是副库算力不足

复制延迟常常不是复制参数本身造成的。一次批量更新几百万行，会让后续小事务排队；副库上有人跑全表扫描，也会和复制 SQL 线程争抢磁盘。可以先看 InnoDB 事务和锁等待：

SELECT trx_mysql_thread_id, trx_started, trx_state, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;

SELECT * FROM performance_schema.replication_applier_status_by_worker\G

单线程复制时，一个慢事务就可能挡住后面的提交。启用了多线程应用，也要关注同一库、同一行或外键约束形成的串行边界。此时盲目增加 worker 数量通常不会立刻解决问题，甚至会放大磁盘抖动。

处理顺序：先止住新增积压，再验证副库追赶

1. 确认是否有大事务或异常 SQL，必要时在业务侧暂停批量写入。
2. 确认副库磁盘延迟、CPU、内存和临时表情况，避免把资源瓶颈误当成复制配置问题。
3. 在可回退窗口内评估并行复制参数，先观察 worker 错误、提交顺序和 relay log 空间。
4. 只有当读流量风险可控且数据一致性策略明确时，才做临时读流量调整。

恢复过程中每隔固定采样窗口记录一次位置和队列空间。延迟下降但 relay log 仍持续增长，说明只是时间指标短暂好看；位置差和 relay log 空间同时收敛，才更接近真正追平。

最小验证清单

修复后至少保留一轮完整证据：IO/SQL 线程为运行状态，错误字段为空，读取与执行位置差距不再扩大，relay log 空间回落，副库关键业务查询延迟恢复。对于需要高一致性的读请求，再用业务数据校验或 GTID 位置做最终确认。

相关问题

Seconds_Behind_Master 是 NULL 要怎么办？

先看 IO、SQL 线程状态和 Last_*_Error，再判断是否存在未提交长事务；不要直接把 NULL 当成“延迟无限大”。

Relay_Log_Space 越来越大说明什么？

通常表示接收速度超过应用速度，但还要结合读取位置和执行位置确认，来源连接中断时也可能出现其他表现。

把复制线程数量调大就能解决延迟吗？

不能保证。只有事务之间存在可并行空间且副库资源足够时，多线程应用才可能有效；锁冲突和磁盘瓶颈需要先处理。

小结

MySQL 主从延迟排查的关键，是把时间指标还原成复制链路：谁在读、谁在执行、队列是否变长、哪个事务挡住了提交。先用状态和位置确定阶段，再用事务与资源信息解释原因，最后做小范围参数调整和连续验证，处理过程才可控。