MySQL 主从延迟排查

主从延迟：主库写入完成后，从库需要几秒、几十秒甚至几分钟才能同步完成，是生产环境最高频的数据库问题。正常同步延迟应在 1 秒以内；延迟过高会直接导致：读写分离查到旧数据、主从数据不一致、主从切换失败。

复制原理、搭建步骤、并行复制开启命令见 mysql-replication-guide，本页专注延迟的根因定位与解决。

一页速查：6 大根因

一、单线程重放瓶颈（最核心、最常见）

原理：MySQL 5.6 及以下版本，从库 SQL 线程单线程串行重放日志；而主库可以多连接并发写入。主库写入并发量越大，从库重放压力越大，延迟越严重——这是架构性瓶颈，不是调参能绕过的。

真实案例：电商秒杀场景，主库 1000+ 并发写入订单数据，主库瞬间完成，从库单线程慢慢重放，直接产生 30s+ 延迟。

解决：

• 升级到 MySQL 5.7+ 并开启并行复制，多线程重放日志
• 核心参数 slave_parallel_workers = 8（按服务器核心数调整，建议 CPU 核数的 50%~80%）
• 配合基于 GTID 的并行复制，重放效率大幅提升
• 完整开启命令（slave_parallel_type = LOGICAL_CLOCK + slave_preserve_commit_order）见 mysql-replication-guide 的「复制延迟过大」一节

二、大批量数据操作（大事务引发延迟）

原理：大批量 UPDATE/DELETE/INSERT（如一次性更新 10 万行）在 ROW 模式下，Binlog 会记录每一行的变更前后内容，日志体积暴增。主库执行大事务可能 1 秒完成，从库却要逐行解析、重放，耗时成倍增加，直接引发秒级/分钟级延迟。

排查命令：

SHOW SLAVE STATUS\G   -- 查看从库延迟时间（Seconds_Behind_Master）
SHOW PROCESSLIST;     -- 查看从库正在执行/重放的事务

解决：

• 禁止一次性执行超大事务，拆分批量 SQL 分批执行：一次性更新 10 万条 → 拆成 10 次、每次 1 万条
• 数据清理、批量更新等重操作安排在业务低峰期执行
• 生产经验：90% 的同步延迟都是大事务导致的，遇到延迟先查主库有没有批量任务在跑

三、主从硬件性能差距

原理：常见架构误区——主库用高配服务器（SSD、多核、大内存），从库用低配机器。主库写入快，从库磁盘 IO / CPU / 内存跟不上，日志重放速度长期低于主库写入速度，延迟日积月累。

真实案例：主库 16 核 32G + SSD，从库 4 核 8G + 机械硬盘。日常小流量看不出问题，高峰期直接 10s+ 延迟。

解决：

• 主从硬件配置保持一致，从库不低于主库
• 从库使用 SSD 磁盘，提升 IO 读写速度
• 优化从库内存参数：增大 innodb_buffer_pool_size（参数细节见 mysql-performance-config）

四、网络延迟与带宽瓶颈

原理：主从跨机房、跨网段部署时，网络波动、带宽不足、丢包超时，会导致从库 IO 线程拉取 Binlog 缓慢，日志传输不及时，产生同步延迟。特征是延迟随网络质量波动。

排查命令：

ping 主库IP            # 测试主从网络延迟、丢包
telnet 主库IP 3306     # 测试端口连通性

解决：

• 核心业务主从同机房部署，减少网络损耗；跨机房只放非核心从库
• 优化网络带宽，关闭服务器上的多余限速策略
• 开启 MySQL 半同步复制，保障日志传输可靠性（配置命令见 mysql-replication-guide）

五、从库索引缺失、SQL 执行缓慢

原理：主库执行无索引的更新/删除时，因为并发高、内存大，速度尚可容忍；但从库是单线程重放，无索引 SQL 触发全表扫描会执行极慢，并且卡住后续所有同步日志，造成大规模延迟。

真实案例：开发上线一条无索引的更新 SQL，主库执行 0.5 秒，从库全表扫描执行 20 秒，同步延迟直接飙升 20s+。

解决：

• 所有业务表必须建立合理索引，禁止无索引的增删改上线
• SQL 上线前审核，避免慢 SQL 同步到从库（慢 SQL 优化方法见 mysql-slow-query-case-study）
• 开启从库慢查询日志，及时发现低效同步 SQL

六、主从参数配置不合理

部分参数默认配置过于保守，从库性能无法发挥，表现为长期性延迟：

• innodb_buffer_pool_size 过小：缓存不足，重放时频繁读写磁盘
• relay_log_space_limit 过小：中继日志空间受限，无法批量拉取日志
• 未开启并行复制、半同步复制：同步效率停留在最低水平

万能四步排查流程（生产直接套用）

步骤 1：查看延迟核心数据

SHOW SLAVE STATUS\G    -- 8.0.22+ 用 SHOW REPLICA STATUS\G

重点关注 Seconds_Behind_Master（延迟秒数）、Relay_Log_Space（中继日志积压）。

步骤 2：判断延迟类型（分流）

• IO 线程异常（Slave_IO_Running 非 Yes）→ 往网络、权限、Binlog 方向查（对应根因 4，或复制中断类故障）
• SQL 线程异常（Slave_SQL_Running 非 Yes 或重放慢）→ 往慢 SQL、大事务、索引缺失方向查（对应根因 1/2/5）

步骤 3：定位具体慢事务

SHOW PROCESSLIST;                              -- 从库正在重放什么
SHOW BINLOG EVENTS IN 'mysql-bin.000001';      -- 翻 binlog 定位大事务
SELECT * FROM information_schema.innodb_trx;   -- 是否锁等待阻塞回放（来自 [[database-troubleshooting-checklist-mysql-redis]] 故障 2）

步骤 4：针对性优化 拆分大事务、优化索引、开启并行复制、升级硬件、优化网络——按上面 6 大根因对号入座。

延迟预防清单（日常纪律）

• 禁止超大事务：批量操作拆小、低峰执行（90% 的延迟源于大事务）
• 业务表强制有索引，无索引增删改不得上线
• 从库不要写数据：会导致主从数据不一致、复制报错
• 从库硬件配置不低于主库，SSD 起步
• 开启从库慢查询日志 + Seconds_Behind_Master 监控告警（监控脚本见 mysql-replication-guide）

关联页面