适用范围与前提
本文面向 MySQL 8.4 单源异步复制，配合「MySQL 主从高可用」场景使用。多源复制需按通道分别采样；其他版本先核对字段名称。准备可查询复制状态的账号、实例与通道清单、统一时间轴，以及告警前后的业务写入和主机指标。以下是待环境验证的排查流程，不是实际故障复盘。
先确认复制是否还在运行
在副本执行只读查询，并记录采样时间、实例标识及完整输出：
SELECT NOW(), @@server_uuid, @@version;
SHOW REPLICA STATUS\G先查看 Replica_IO_Running、Replica_SQL_Running 和最后错误。如果线程停止，优先依据错误定位认证、连接、日志可用性或应用事务失败；把「已停止」与「仍在追赶」分开记录。错误字段可能保留历史信息，应结合时间和当前线程状态判断。
不把延迟秒数当作唯一结论
Seconds_Behind_Source 为 0 不能单独证明副本已追上源库：接收链路变慢时，应用线程可能只追上已接收的日志。NULL 也不能当作零延迟。字段含义和限制见文末的 SHOW REPLICA STATUS 官方说明。
建议连续采集多个观察点，同时记录业务写入量、接收位置、执行位置和 relay log 大小。使用 GTID 时对照接收与执行集合；未用 GTID 时同时比较日志文件名和位置，不能直接相减不同文件中的数字。确认是否配置了预期的延迟复制，避免把策略当故障。
区分接收慢与应用慢
源库持续产生事务而接收进度基本不变时，沿源库连接、网络重传、带宽和日志保留范围查证。接收进度持续前移、执行进度落后且积压增大时，再检查副本 CPU、磁盘延迟、可用空间、锁等待和大事务。
将高负载时间段与备份、批处理、DDL 或读流量变化对齐。复制线程仍为 Yes 只说明线程运行，不代表吞吐足够。每次提出一个假设，并写明能支持或推翻它的证据，避免同时调整多个参数后无法归因。
若只有一个副本异常，对照正常副本的硬件、读负载和连接路径；若多个副本同时出现积压，优先检查共同的源端写入变化。把这种横向比较与时间趋势一起保留，便于下一位值班人员继续排查。
根据证据安排处置
优先选择可控的业务降载或错峰方案，并保留变更前的指标。应用瓶颈涉及并行复制时，先确认当前配置、事务依赖和资源余量，在验证环境评估后再调整；不要把增加 worker 数当成通用解法。遇到重复键、缺行等错误，先保存错误上下文和数据证据，不用跳过事务来掩盖一致性问题。
验收与停止条件
验收应覆盖一个有代表性的业务负载窗口：线程稳定、无新增复制错误、积压持续收敛，并通过业务允许的数据新鲜度检查。记录实测结果，阈值由业务目标确定，不预设「恢复到某秒即成功」。若积压继续增长、磁盘趋满或错误指向数据分歧，应停止性能调参，保全日志并转入容量或一致性处置。撤销本次临时降载或配置调整时逐项恢复并继续观察。