RDBMySQL如何优化数据查询方案

总结/EdisonZhou

对于后端开发面试，关系型数据库是一个必问考点。而在目前主流的关系型数据库中，MySQL无疑是互联网圈中最火热的一个。掌握MySQL的核心知识点，对于面试取得一个好成绩很重要！

我们都知道在互联网应用场景中，在MySQL之前需要设置一个Redis作为缓存来提高系统性能。但是，我们需要有一个基础认知：缓存不能解决所有问题！

应用缓存的原则之一就是保证缓存命中率足够高，如果不高，还是有很多请求打到DB。例如在"订单中心"之类的场景中，每个用户的订单都不同，除非全量缓存DB订单信息，不然缓存命中率会很低。因此，缓存只能作为DB的前置保护机制。

读写分离背景

当单台MySQL无法满足要求时，只能用多个具有相同数据的MySQL组成集群来承担大量的读写请求。

主从复制原理

MySQL的读写分离的核心机制是主从复制，它的原理如下图所示：

这个过程经历了大概如下三个阶段：

（1）阶段1：写入Binlog=主库写入binlog日志，提交事务，并更新本地存储数据；

（2）阶段2：同步Binlog=将binlog复制到所有从库上，每个从库将binlog写到暂存日志中；

（3）阶段3：回放Binlog=回放binlog，并更新存储数据；

主从复制模型

MySQL的主从复制大概有如下三个模型：

（1）同步复制（不适合互联网场景）：事务线程要等待所有从库的复制成功响应；

（2）异步复制（响应快但存在数据丢失风险）：事务线程完全不等待从库的复制成功响应；

（3）半同步复制（MySQL5.7之后新增的方式）：事务线程只要等待一部分从库复制成功响应回来就行，不存在数据丢失风险；

主从复制的延迟

对于MySQL的主从复制，我们需要有一个基础认知：MySQL主从复制始终都存在延迟的问题。

那么，如何尽量解决复制延迟带来的可能问题呢？

以电商平台发布评论场景为例，它会先调用评论审核，目的是针对评论进行言论监控和图片鉴黄等操作。在此场景下我们可以有以下几个方案：

（1）使用数据冗余：异步调用审核模块时，发送商品ID+评论消息体，但此方案会占用带宽和通信时间；

（2）使用缓存：在写入数据主库时，同时将评论数据写到Redis缓存中，其他线程获取评论时优先查询缓存，但此方案会带来缓存和DB的一致性问题；

（3）直接查询主库：如果提前明确了查询的数据量不大就可以使用此方案，否则会出现主库的性能压力较大；

实现主库与从库的访问

对于实现MySQL的主库和从库的正确访问，我们可以有以下两种方法：

（1）方法一：提前将所有数据源配置在工程中，每个数据源对应一个主库或从库，在代码逻辑中进行判断，将SQL语句发给指定的数据源处理；

此方法代码侵入业务逻辑，不利于代码的维护；

（2）方法二：借助独立部署的代理中间件如MyCat，通过使用标准的MySQL通信协议，代理多个数据库；

此方法适合有独立运维团队的公司，且所有SQL都需要跨两次网络传输；

基础认知

大促流量大时，并不是多增加几台从库就可以抗住大促的高并发请求。

原因分析

从库数量的增加也意味着从库连接到主库的I/O线程也较多，主库需要创建同样多的logdump线程来处理复制请求。这对主库的资源消耗比较高，同时还受限于主库的网络带宽。

最佳实践

实际使用中，一般一个主库跟2~3个从库。

抽象运作机制

通过对其复制过程的抽象，它的本质上就是一个复制状态机，通过日志复制和回放的方式来实现集群中所有节点内的状态一致性。

举一反三总结

（1）MySQL的主从复制（基于binlog）

（2）RedisCluster的主从复制（基于replicationbacklog）

（3）MongoDB的复制集（基于oplog）

（4）Raft协议（相关产品：TiDB）

本文总结了MySQL的数据查询优化、读写分离、主从复制相关的知识点，希望能对你有所帮助！不过，本文只是高层概览，更详细的细节还是需要你参考更多扩展资料才能应对面试的需求。下一篇，我们会聚焦MySQL如何优化数据存储的方案，即在写多读少的场景下如何优化写入性能。