主从延迟情况 我们先看看，哪些情况会导致主从延时： 从库机器性能：从库机器比主库的机器性能差，只需选择主从库一样规格的机器就好。 从库压力大：可以搞了一主多从的架构，还可以把 binlog 接入到 Hadoop 这类系统，让它们提供查询的能力。 从库过多：要避免复制的从节点数量过多，从库数据一般以3-5个为宜。 大事务：如果一个事务执行就要 10 分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟 10 分钟啦。日常开发中，不要一次性 delete 太多 SQL，需要分批进行，另外大表的 DDL 语句，也会导致大事务。 网络延迟：优化网络，比如带宽 20M 升级到 100M。 MySQL 版本低：低版本的 MySQL 只支持单线程复制，如果主库并发高，来不及传送到从库，就会导致延迟，可以换用更高版本的 MySQL，支持多线程复制。 主从延时解决方案 面试时，有些同学能回答出使用缓存、查询主库、提升机器配置等，仅仅这些么？ 最容易想到的方法，缩短主从同步时间： 提升从库机器配置，可以和主库一样，甚至更好； 避免大事务； 搞多个从库，即一主多从，分担从库查询压力； 优化网络宽带； 选择高版本 MySQL，支持主库 binlog 多线程复制。 也可以从业务场景考虑： 使用缓存：我们在同步写数据库的同时，也把数据写到缓存，查询数据时，会先查询缓存，不过这种情况会带来 MySQL 和 Redis 数据一致性问题。 查询主库：直接查询主库，这种情况会给主库太大压力，核心场景可以使用，比如订单支付。 如果能把上面基本回答出来，就已经非常厉害了，还有么？ 其实还可以在 MySQL 架构上来考虑。 主库对数据安全性较高，设置配置如下： sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 而 slave 不需要这么高的数据安全，完全可以将 sync_binlog 设置为 0，或者关闭 binlog，innodb_flushlog 也可以设置为 0，来提高 sql 的执行效率。 架构方案：使用多台 slave 来分摊读请求，再从这些 slave 中取一台专用的服务器，只作为备份用，不进行其他任何操作，比如设置 sync_binlog 为0，或者关闭 binglog 等，提升从库查询性能。 ...

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