MySQL主从复制延迟7个原因与排查方法

先说说我的判断：主从复制延迟这个问题，在MySQL运维中间出现的频率非常高。很多线上事故的根源并不是数据库直接宕机，而是主从复制已经严重延迟了，业务侧却没有第一时间感知到。

主从延迟一旦开始扩大，最先遭殃的就是读写分离。用户刚提交的数据查不到、订单状态对不上、库存更新明显滞后——这些现象背后，往往都站着复制延迟。更严重的是，如果这个时候主库出了故障，从库根本来不及切换。

而且，主从延迟从来不会只有一个原因。它背后可能牵扯到SQL性能、磁盘IO、网络抖动、大事务、锁等待、复制模式、硬件配置等一系列因素。

下面把生产环境里最常见的7类主从延迟原因，以及对应的排查方法，梳理一下。

排查前先看复制状态

在动手排查之前，通常先执行这个命令：

SHOW SLA VE STATUS\G

重点关注以下几个字段：

• Seconds_Behind_Master
• Sla ve_IO_Running
• Sla ve_SQL_Running

不过要注意，Seconds_Behind_Master并不总是靠谱的。在大事务执行、SQL线程阻塞这类场景下，它可能显示正常，但实际上已经严重延迟了。很多团队会额外配合pt-heartbeat这类工具来做更精准的监控。

原因1：从库硬件配置明显低于主库

不少团队会默认“从库压力不大”，于是主库用高配SSD和高IO实例，从库却只配了一台低规格云主机。

实际情况是，从库不只承担复制，还得消化读流量、跑报表、做备份。主库写入量一上来，从库同样要执行这些SQL。如果CPU、内存或者磁盘IO能力跟不上，relay log就会不断堆积，延迟越拉越大。

排查方法：对比主从的CPU核数、内存大小、磁盘类型和云盘IOPS。配置差距过大，复制延迟基本无解。

原因2：从库存在慢查询或MDL锁等待

很多业务会把报表、统计任务扔到从库跑，但如果这些SQL涉及全表扫描、大范围JOIN、临时表或filesort，就会大量占用资源，直接影响SQL线程执行relay log。

排查方法：执行SHOW PROCESSLIST看看有没有长时间运行的SELECT，同时开启慢查询日志，分析那些拖后腿的SQL，优化索引。

另外，DDL引起的MDL锁阻塞也很常见。比如主库执行ALTER TABLE，从库的SQL线程可能卡在metadata lock上，复制就会长时间停摆。

原因3：主库写入压力过大，binlog生成太快

如果主库持续高频UPDATE、批量INSERT、大量DELETE，binlog会像滚雪球一样快速增长。在row-based replication模式下，每一行变更都会增加从库回放的压力。从库SQL线程处理速度一旦跟不上，延迟就会持续扩大。

排查方法：关注主库的写入QPS、binlog产生速率，以及从库的apply速度，这三项数据能说明问题。

原因4：大事务导致复制线程长时间阻塞

这应该是线上最容易造成“延迟尖刺”的原因。MySQL复制是以事务为单位回放的，一个事务没执行完，后面的事务就得排队等着。比如一次DELETE影响了几百万行，这个事务在从库必须完整走完，期间整个SQL线程都会被堵死。

排查方法：检查binlog里有没有大事务，业务层面尽量避免一次性处理太多数据，建议分批提交。

原因5：主从网络出现抖动或带宽不足

虽然大多数复制延迟不是网络导致的，但如果跨地域部署、专线不稳定、带宽不够、网络丢包，IO线程拉取binlog的速度就会受影响。

排查方法：观察SHOW SLA VE STATUS中的Master_Log_File和Read_Master_Log_Pos是否长时间不变化。用ping、traceroute、iperf测试一下网络质量，基本能定位。

原因6：relay log异常或磁盘空间不足

正常情况下relay log会自动清理。但如果SQL线程卡住了，延迟持续扩大导致relay log无法消费，这些日志就会不断堆积。磁盘空间一旦被占满，复制线程很可能直接中断。

排查方法：执行df -h检查磁盘使用率，再看MySQL错误日志里有没有relay log相关的报错。

原因7：未开启并行复制，SQL线程处理能力不足

MySQL 5.6开始支持并行复制，但真正适合高并发场景的，是MySQL 5.7之后基于sla ve_parallel_type=LOGICAL_CLOCK的并行复制模式。

排查方法：执行SHOW VARIABLES LIKE 'sla ve_parallel_workers'，如果值是0或1，说明并行度严重不足。可以根据业务情况调整到4~8甚至更高。

快速排查步骤总结

实际线上排查时，按这个顺序快速检查一遍，效率会高很多：

1. SHOW SLA VE STATUS\G — 看延迟和复制线程状态
2. 系统负载检查：top、iostat、df -h
3. 从库是否有慢查询或锁等待：SHOW PROCESSLIST
4. 分析主库binlog增长速度和写入压力
5. 测试主从网络质量
6. 检查是否开启并行复制

关于数据库复制稳定性的行业做法

主从复制延迟是数据库运维中最常见的痛点之一。很多中小企业没有专职DBA，出了问题才临时翻文档，效率低还容易误操作。

日常巡检中持续监控主从延迟、慢SQL、磁盘空间、数据库连接池等指标，延迟超过阈值时主动告警并协助分析根因，这其实比“出事后救火”更有意义。

当然，无论有没有外部支持，把上面这7个原因的排查方法整理成SOP，并在测试环境定期演练，都是值得投入的事。毕竟，主从延迟从来不会提前通知你。

（完）