数据库主从延迟突然扩大：大事务的影子

发布时间:2026-02-06 03:04

## 症状 主从架构平时延迟毫秒级，某天监控曲线突然抬升到秒级乃至分钟级，从库读取的数据明显滞后，依赖从库的业务出现数据不一致的投诉。主库写入量看起来并没有暴涨，延迟却迟迟不回落，越积越高。 ## 定位 从延迟指标入手。 ``` SHOW SLAVE STATUS; ``` 看延迟秒数与正在执行的中继日志位置，确认从库在持续回放而非停滞。回放停滞是另一类问题，先排除。延迟的源头在主库日志里：回放是串行的，主库上一个跑了几分钟的大事务，从库要用同样长的时间回放，期间后续事务全部排队。常见的大事务制造者：一次性更新千万行的批量语句、忘记分批的数据订正、大批量的导入导出。把延迟抬升时刻与主库的慢日志对表，时间戳吻合的那条超长事务就是真凶，事务的持续时长与延迟的抬升幅度对得上，证据链就闭合了。 ## 解决 当下的大事务让它跑完，中断它反而要处理回滚的成本。从库侧可以开启并行回放并配置合理的并行度，让具备并行条件的事务分头执行。根治在流程：批量变更必须分批，单批控制在秒级完成量级；数据订正脚本默认带分批逻辑，绝不裸跑全表更新。批量导入走专门的导入通道而非普通插入。 ## 预防 延迟指标纳入告警，阈值设在业务能容忍的读滞后之内。变更窗口的规范里写明单事务的规模上限，评审时人工把关这一条。批量脚本的评审重点看两处：有没有分批、批次之间有没有间隔，两处都过关才放行。定期演练大变更的分批节奏，让规范停留在肌肉记忆里而不是文档里。顺云云服务器上跑主从架构时，把从库延迟与主库慢日志的监控联动起来看，延迟异常时先翻主库那几分钟在跑什么，方向极少出错。