“从库延迟几小时了，主从数据已经差了几百万条。”
这是MySQL运维中很常见的一类问题。很多线上事故并不是数据库直接宕机，而是主从复制已经严重延迟，但业务侧还没有第一时间发现。
一旦主从延迟持续扩大，最直接的问题就是读写分离开始出现异常。用户刚提交的数据查不到、订单状态不同步、库存更新延迟，严重时甚至会导致主库故障后，从库无法及时切换。
而且主从延迟往往不是单一问题，它背后可能涉及：SQL性能、磁盘IO、网络、大事务、锁等待、复制模式、硬件配置等。
下面整理了生产环境里最常见的7类主从延迟原因，以及对应的排查方法。
排查前先看复制状态
在排查之前，通常先执行：
SHOW SLAVE STATUS\G
重点关注：
Seconds_Behind_MasterSlave_IO_RunningSlave_SQL_Running
需要注意的是，Seconds_Behind_Master并不一定完全准确。在大事务执行、SQL线程阻塞等场景下，它可能出现“显示正常但实际已经严重延迟”的情况。很多生产环境会结合pt-heartbeat等工具监控真实复制延迟。
原因1：从库硬件配置明显低于主库
很多团队会默认认为“从库压力不大”，于是主库使用高配SSD和高IO实例，而从库却使用低规格云主机。
事实上，从库不仅承担复制，还可能承担读流量、报表分析、备份等任务。当主库写入量增大时，从库同样需要执行这些SQL。如果CPU、内存或者磁盘IO能力不足，relay log就会不断堆积。
排查方法：对比主从的CPU核数、内存大小、磁盘类型（SSD/HDD）和云盘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 SLAVE STATUS中的Master_Log_File和Read_Master_Log_Pos是否长时间不变化。使用ping、traceroute、iperf测试网络质量。
原因6：relay log异常或磁盘空间不足
正常情况下relay log会自动清理。但如果SQL线程卡住、延迟持续扩大导致relay log无法消费，relay log会不断堆积。磁盘空间被占满后，复制线程可能直接中断。
排查方法：执行df -h检查磁盘使用率，查看MySQL错误日志中关于relay log的报错。
原因7：未开启并行复制，SQL线程处理能力不足
MySQL 5.6开始支持并行复制，但真正适合高并发场景的是MySQL 5.7之后基于slave_parallel_type=LOGICAL_CLOCK的并行复制模式。
排查方法：执行SHOW VARIABLES LIKE 'slave_parallel_workers'，如果值为0或1，说明并行度不足。可根据业务情况调整为4~8甚至更高。
快速排查步骤总结
实际线上排查时，可以按这个顺序快速检查：
SHOW SLAVE STATUS\G查看延迟和复制线程状态- 查看系统负载：
top、iostat、df -h - 检查从库是否有慢查询或锁等待：
SHOW PROCESSLIST - 分析主库binlog增长速度和写入压力
- 测试主从网络质量
- 检查是否开启并行复制
关于数据库复制稳定性的行业做法
主从复制延迟是数据库运维中最常见的痛点之一。很多中小企业没有专职DBA，出了问题才临时查文档，效率低且容易误操作。
据了解，像江苏立维这样的运维服务商，会在日常巡检中持续监控主从延迟、慢SQL、磁盘空间、数据库连接池等指标，并在延迟超过阈值时主动告警，协助分析根因。对于没有精力自建数据库运维体系的团队，通过持续巡检和异常分析来提前发现复制链路的问题，其实比“出事后救火”更重要。
当然，无论是否使用外部服务，把上述7个原因的排查方法整理成SOP，并在测试环境定期演练，都是值得投入的事情。毕竟，主从延迟不会提前通知你。
（完）
