前面几篇文章和小伙伴们聊的基本上都是从索引的角度去优化 MySQL 查询，然而，索引创建的好，并不意味着查询就一定快，影响查询效率的因素特别多，今天我们就来聊一聊这些可能影响到查询的因素。
1. 查询流程
开始今天的内容之前，先来和小伙伴们大概捋一捋 MySQL 的查询流程。我们来看如下一张图：
- 首先，用户通过连接器和服务端之间建立通信连接，这个说白了就是一个 Socket 通信，用户名/密码的校验，用户权限的判断等等，都是在这个连接器中完成的。
- 接下来需要对我么传入的 SQL 进行解析，这块跟代码的执行流程其实差不多，先做词法分析，识别出各种关键字，然后再做语法分析，语法分析就是根据 MySQL 的各种语法规则，去判断 SQL 是否满足语法规则。
- 接下来就是查询优化器出场，查询优化器就是分析要执行的 SQL，判断应该选择哪一个索引，包括在多表联合查询的时候，各个表的连接顺序也是由查询优化器来决定的，优化器执行完毕之后，会生成查询执行计划，我们平时通过 explain 关键字查看到的就是这个。
- 最后就是执行器了，执行器调用搜索引擎提供的具体接口去获取数据。
这张图大家大概有个印象，在后续的 MySQL 查询和优化中，很多东西就容易理解了。
接下来我们就来看看什么情况下查询会变慢。
2. 查询了不需要的记录
数据按需取用。有时候我们会忽略多拿数据对查询性能的影响，然而优化是一个锱铢必较的事情，需要多少数据就查询多少，要尽量避免数据库查询 100 条，结果前端只展示 10 条这种情况。如有需要，可以通过 limit 来限制数据库查询出来的数据总量。
如果在查询的时候使用了唯一性索引的话，那么查询到记录之后 MySQL 就停止扫描了；但是如果查询的时候使用的是非唯一性索引的话，那么扫描到第一条记录之后，还会继续向后扫描，直到扫描到第一条不满足条件的记录为止，对于这种情况，如果我们确定查询的结果只有一条，则可以通过 limit 进行限制，设置 limit 1，那么扫描到第一条满足条件的记录之后，就不会继续扫描了。
3. 返回需要的列
查询的时候尽量避免 select *，这个问题在之前的文章中松哥其实和大家聊过了，因为很多时候我们在前端其实并不需要使用到那么多字段，可能只是为了查询简单，直接来一个 select *，有时候列数和数据总量都比较少的时候，这么写也看不出来性能明显的差异，但是当列数和数据量大了，那么 select * 带来的影响就会比较大了。
特别是有的时候多表联合查询，如果用 select * 就会把多张表的查询结果拼接到一起，那么此时查询结果的列数就会成倍增加。
在前面的文章中，松哥也和大家提到过覆盖索引，如果索引设计得当，那么在查询的时候可以通过覆盖索引来提高查询的性能，但是如果使用了 select * 那么大概率是用不了覆盖索引了。
4. 恰到好处的缓存
这里举一个 TienChin 项目的例子，用户登录成功之后，在后续的流程中，经常会用到当前登录用户的信息，如果每次都去数据库查询，每次查询返回结果都是一致的，没有必要，此时我们可以将用户信息存入到 Redis 缓存中，需要的时候从 Redis 中提取就可以了。
在项目中，对于这些需要多次频繁查询，且每次查询返回结果一样的数据，都可以选择将之存入到缓存中以提高查询性能。
5. 关注扫描行数
在查询的时候，我们可以通过 explain 来查看执行计划，执行计划中有一个指标是扫描行数，如下图中的 rows，这个就表示查询优化器预估要扫描多少行记录，filtered 则表示预估满足条件的比例。
一般在单表查询时候我们并不会特别关注 filtered 字段，在多表联合查询的时候会比较关注该字段的值。
6. 关注扫描类型
这一条实际上就是让大家关注前面查询计划中的 type 字段的值，type 字段的取值有很多种，例如常见的 index、ALL、range、const 以及 ref，还有一些不常见的如 system、eq_ref、fulltext、ref_or_null、index_merge、unique_subquery、index_subquery 等，每一种都代表了不同的查询计划，再结合查询计划中的 Extra 字段中的值，我们大致上可以将查询分为三种类型：
- 直接调用存储引擎层进行查询，查询结果在 MySQL Server 层不需要额外处理，直接返回给客户端即可。
- 直接从索引中过滤出来想要的值并返回给客户端，这种时候，过滤虽然发生在 MySQL Server 层，但是由于不需要回表，效率也还过得去。
- 从数据表中查询到相应的记录，然后在 MySQL Server 层进行过滤，过滤的同时可能还需要回表，此时效率就会低一些。
