如何解决 MySQL 主从延时问题？-云智核

如何解决 MySQL 主从延时问题？

发布时间：2025-11-05 15:02:56 来源：云智核作者：IT科技类资讯

大家好呀，何解我是问题楼仔。

最近面试了十几个同学，何解关于 MySQL 主从延时问题，问题我一般都会问。何解

对于这“三连问”，极少有同学能通关，何解甚至有同学连主从复制原理都不清楚。问题

这个并不是何解存粹的八股文，因为在实际工作场景中，问题很多同学都遇到过。何解

不 BB，问题上文章目录。何解

有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。

主从延迟，其实就是“从库回放” 完成的时间，亿华云计算与 “主库写 binlog” 完成时间的差值，会导致从库查询的数据，和主库的不一致。

探讨这个问题前，我们需要知道主从复制的原理。

MySQL 的主从复制是依赖于 binlog，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步地完成。

详细流程如下：

我们分析一下主从复制的过程。

MySQL 的主从复制都是单线程的操作，主库对所有 DDL 和 DML 产生 binlog，binlog 是顺序写，所以效率很高。

Slave 的 Slave_IO_Running 线程会到主库取日志，放入 relay log，效率会比较高。

Slave 的 Slave_SQL_Running 线程将主库的 DDL 和 DML 操作都在 Slave 实施，DML 和 DDL 的 IO 操作是随机的，不是顺序的，因此成本会很高。

还可能是 Slave 上的其他查询产生 lock 争用，由于 Slave_SQL_Running 也是高防服务器单线程的，所以一个 DDL 卡住了，需要执行 10 分钟，那么所有之后的 DDL 会等待这个 DDL 执行完才会继续执行，这就导致了延时。

总结一下主从延迟的主要原因：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。

我们先看看，哪些情况会导致主从延时：

面试时，有些同学能回答出使用缓存、查询主库、提升机器配置等，仅仅这些么？

最容易想到的方法，缩短主从同步时间：

也可以从业务场景考虑：

如果能把上面基本回答出来，就已经非常厉害了，还有么？

其实还可以在 MySQL 架构上来考虑。

主库对数据安全性较高，设置配置如下：

而 slave 不需要这么高的数据安全，完全可以将 sync_binlog 设置为 0，或者关闭 binlog，innodb_flushlog 也可以设置为 0，来提高 sql 的执行效率。

架构方案：使用多台 slave 来分摊读请求，再从这些 slave 中取一台专用的服务器，只作为备份用，不进行其他任何操作，比如设置 sync_binlog 为0，或者关闭 binglog 等，提升从库查询性能。

再问一下，还有么？可以文末私信我哈~~

再回过头来看这个问题，估计很多同学能回答出一二，但是这个不能成为你的加分项。

面对如此激烈的竞争环境，同样一个问题，你就需要比别人掌握得更多，回答得更全面，面试官才能对你刮目相看。

其实我当年面试小米时，也面试过这个问题，当时就是基于上面回答的。

后来的一次 MySQL 分享，讲得还不错，当时我们主管就说，楼仔的 MySQL 掌握得挺好的，记得当时面试时，我就问过一个 MySQL 主从复制问题，他都能回答到非常底层。

我没想到，这都一年多了，当时的那场面试，居然给我主管留下那么深刻的映像。

随便看看