如何处理 MySQL 的主从同步延迟？

日期：2026-07-11
难度：中等
标签：#面试 #MySQL #复制延迟 #场景题

一句话答案

先判断延迟发生在拉取还是回放，再从大事务、从库资源、并行度、索引和网络定位根因；对一致性敏感读走主或等待 GTID，不能靠盲目扩容掩盖问题。

面试口语版

我会先看副本状态和 Seconds_Behind_Source，但不只依赖这个指标，还要看 relay log 堆积、applier 延迟、CPU/IO、网络和大事务。I/O 线程慢一般查网络、主库 binlog 发送；SQL/applier 慢常见于大事务、从库性能弱、缺索引导致回放慢或单线程瓶颈。措施包括把大事务拆批、让从库配置和索引不弱于主库、启用并合理配置多线程回放、控制 DDL 和热点写入。业务侧对写后读和库存等强一致请求读主，或使用 GTID wait；非关键读允许最终一致并在副本超阈值时摘流。

关键细节

• Seconds_Behind_Source 可能为 NULL 或不准确，要配合位点/GTID、队列长度和应用时间观测。
• 并行复制受事务依赖关系限制，不是线程越多越快。
• 先修复写入模型和大事务，再考虑读写分离或增加副本。

面试官追问

1. 如何判断是 I/O 线程还是 SQL 线程落后？
2. 大事务为什么会放大延迟？
3. 写后读一致性如何实现？

学习清单

• 准备“监控—定位—数据库优化—业务降级”四步回答。