MySQL 复制延迟会造成读写不一致、报表数据滞后，严重时影响故障切换。Seconds_Behind_Master 只是表象，必须判断延迟发生在接收 binlog、写 relay log，还是应用 relay log 的阶段。
一、先确认复制拓扑与影响
记录主库、从库、复制通道、业务读流量和故障开始时间。MySQL 8 可执行：
SHOW REPLICA STATUS\G较旧版本使用：
SHOW SLAVE STATUS\G重点字段：
Replica_IO_Running：I/O 线程是否正常。Replica_SQL_Running：SQL 线程是否正常。Seconds_Behind_Source：当前估算延迟。Last_IO_Error、Last_SQL_Error：最近错误。Relay_Log_Space：relay log 是否快速增长。Source 与 Exec 位点或 GTID 差距。
复制线程停止时，延迟字段可能为 NULL 或不再真实变化，不能据此判断“没有延迟”。
二、判断是 I/O 还是 SQL 应用慢
I/O 线程异常
如果 Replica_IO_Running=No，检查网络、账号权限、主库 binlog 保留、TLS 和磁盘空间：
ping <source_ip>
nc -vz <source_ip> 3306
df -hT同时查看 MySQL error log。不要在没有确认位点和 GTID 状态前使用跳过事务的方式恢复。
SQL 线程正常但应用落后
SHOW PROCESSLIST;
SELECT * FROM performance_schema.replication_applier_status_by_worker\G若某个 worker 长期执行同一事务，通常是大事务、慢 SQL、锁等待或从库资源瓶颈。
三、检查锁等待与长事务
SELECT * FROM information_schema.innodb_trx\G
SELECT * FROM performance_schema.data_lock_waits\G检查从库上是否有报表查询、备份或 DDL 阻塞复制。只读从库也可能因为长查询占用资源或影响 purge。终止会话前必须确认业务和事务影响。
四、检查 CPU、磁盘和内存
top
vmstat 1 10
iostat -xz 1 10
pidstat -dru -p $(pidof mysqld) 1 10重点关注：
CPU 是否被单核打满；
磁盘
await、利用率和队列是否升高；是否发生 swap；
relay log、binlog 和数据目录是否在慢盘；
从库是否同时承担大量查询、备份或统计任务。
五、定位主库大事务和写入突增
检查主库 TPS、binlog 生成速率、慢日志和最近发布。大批量更新、无索引更新、一次提交数百万行，都会让从库长时间追赶。
重点确认是否存在：
大事务或批量删除；
DDL 变更；
热点表高频更新；
主从硬件性能差异；
单线程复制无法利用多核。
解析 binlog 可能消耗大量资源，应在隔离环境处理，不要直接给繁忙主库增加压力。
六、应急处理步骤
暂停或限速非核心批处理和大事务来源。
将报表、备份等负载从延迟从库移走。
临时停止把强一致读流量发送到该从库。
修复锁等待或异常 SQL，观察 relay log 和位点差距是否缩小。
在确认事务依赖和版本支持后，评估提高并行复制 worker。
延迟非常大且追赶时间不可接受时，可从新快照重建从库，但必须保留原节点直到验证完成。
不要通过跳过错误事务来“消除延迟”，这可能造成主从数据永久不一致。
七、评估追赶时间
持续记录每分钟位点差距、relay log 大小或延迟秒数。只有消费速度高于主库新增速度，才能真正追平：
预计追赶时间 = 当前积压事务量 /（从库应用速率 - 主库新增速率）只看某一时刻的 Seconds_Behind_Source 容易误判，应观察趋势。
八、长期治理
大批量任务分批提交，并在上线前评估 binlog 量。
根据版本配置并行复制，验证事务依赖跟踪策略。
从库规格不能长期低于主库写入需求。
监控复制线程、延迟趋势、relay log、错误和 GTID 差距。
读流量根据一致性要求分级，关键查询不要无条件走从库。
定期做主从校验、重建演练和故障切换演练。
主从延迟治理的重点不是把数字临时降到零，而是控制大事务、资源竞争和复制吞吐之间的长期差距。