MySQL 查询什么时候会变慢？

良好的指数创建并不意味着需求会很快。影响民意调查有效性的因素有很多。今天我们就来谈谈这些可能影响需求的因素。

1。查询流程

在开始今天的内容之前，我先和小伙伴们简单回顾一下MySQL的查询流程。我们来看下图：

1. 首先，用户在连接器和服务器之间建立通信链路。说白了，Socket通信、用户名/密码验证、用户权限评估等都发生在这个连接器中。
2. 接下来我们需要解析我们传递的SQL。其实和代码执行过程类似。我们首先进行词法分析来识别不同的关键字，然后进行语法分析。解析基于MySQL。不同的语法规则来判断SQL是否符合语法规则。
3. 下一步是查询优化器。查询优化器分析要执行的SQL并确定应选择哪个索引。当多个表一起查询时，每个表的连接顺序也是由查询优化器决定的。运行优化器后，会生成查询执行计划。这就是我们通常通过explain关键字看到的。
4. 最后一步是执行器，它调用搜索引擎提供的特定接口来检索数据。

这张图你可能会有印象。很多东西在后续的MySQL查询和优化中就会很容易理解。

接下来我们看看什么情况下查询会变慢。

2。搜索了不必要的记录

可根据要求提供数据。有时我们会忽略获取更多数据对查询性能的影响。但优化是每一块钱的事。您可以根据需要查询尽可能多的数据。尽量避免出现 100 个数据库查询只在前端显示 10 个结果的情况。如果需要，您可以使用限制来限制从数据库查询的数据总量。

如果查询中使用了唯一索引，MySQL会在一条记录查询后停止扫描；但如果查询中使用了非唯一索引，则在扫描到第一条记录后，仍然会继续向后扫描，直到扫描到第一条不满足条件的记录。这种情况下，如果我们发现查询结果只有一条，我们可以通过limit来限制，将limit设置为1，那么就会检查第一条符合条件的记录。记录条件后，扫描将不再继续。？需要用到这么多字段，可能只是为了让查询简单，只需 select *。有时，当列数和数据总量相对较小时，以这种方式编写时不会看到任何明显的性能差异。但当列数和数据量增加时，select * 的影响会更大。

特别是多表有共同查询的情况下，如果使用select *，多表的查询结果会合并在一起，查询结果的列数会增加一倍。

在上一篇文章中，宋哥也给大家提到了封面索引。如果索引设计正确的话，查询时通过覆盖索引可以提高查询性能，但是如果使用 select * 那么很大概率不会使用覆盖索引。

4。正确的缓存

这是 TienChin 项目的示例。用户成功登录后，当前登录用户的信息通常会在其他进程中使用。如果每次查询数据库，查询返回的结果都是一致的，那么这是没有必要的。目前，我们可以将用户信息缓存在Redis中，并在需要时从Redis中提取。

在项目中，对于需要多次频繁查询且每次返回结果相同的数据，可以选择缓存以提高查询性能。

5。注意扫描行数。执行计划中的一个指标是扫描的行数，如下图所示的行数。这意味着查询优化器已经准备好了要扫描的估计行数记录，filtered表示满足条件的估计比例。

一般情况下，我们在查询一张表的时候，不会特别关注过滤后的字段，但是在同时查询多张表的时候，我们会更加关注这个字段的值。

6。注意检查的类型

这一项其实可以让大家关注之前查询计划中type字段的值。 type字段的值有多种类型，如常见的index、ALL、range、const、ref等，也有一些不常见的，如system、eq_ref、fulltext、ref_or_null、index_merge、unique_subquery、index_subquery ， ETC。每个代表一个不同的查询计划。结合查询计划中Extra字段的值，我们可以大致将查询分为三种类型：

1. 直接调用查询存储机制层。查询结果不需要MySQL服务器层的额外处理，可以直接返回给客户端。
2. 直接从索引中过滤出需要的值，返回给客户端。目前，虽然过滤发生在MySQL服务器层，但由于不需要返回表，所以效率还不错。
3. 从数据表中找到相关记录，然后在MySQL服务器层进行过滤。过滤的时候，可能还需要返回表，这样效率会比较低。