mysql 慢查询过多_MySQL 慢查询优化

为什么查询速度会慢

1.慢是指一个查询的响应时间长。一个查询的过程：

客户端发送一条查询给服务器
服务器端先检查查询缓存，如果命中了缓存，则立可返回存储在缓存中的结果。否则进入下一个阶段
服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。
MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询。
将结果返回给客户端

2.数据访问

是否向数据库请求了不需要的数据
是否扫描额外的记录

3.查询的方式

一个复杂的查询还是多个简单的查询
切分查询（将大查询切分成小查询，循环完成小查询）
分解关联查询

慢查询分析

问题SQL

把复杂的SQL分成多个简单SQL并执行，查看具体那个字段会慢，区分度不高。

EXPLAIN

显示SQL如何使用索引的执行计划。

执行计划的参数：

table 显示这一行的数据是关于哪张表的

type 显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL

possible_keys 显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句

key 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引

key_len 使用的索引的长度。在不损失精确性的情况下，长度越短越好

ref 显示索引的哪一列被使用了，如果可能的话，是一个常数

rows 扫描请求数据的行数

Extra 关于MYSQL如何解析查询的额外信息

PROFILE

显示SQL执行消耗系统资源的信息。

查询执行的过程

MySQL客户端/服务器通信协议是“半双工”的。客服端/服务器端都可以向对方发送数据，但不能同时发生。所以我们无法也无须将一个消息切成小块独立来发送。
这种协议没办法进行流量控制。
客户端发送请求的数据包大小由参数max_allowed_packet限制。如果查询太大，服务端会拒绝接受更多的数据并抛出相应的错误。
服务器端返回的多个数据包，客户端必须完整接受。

1.查询状态 SHOW FULL PROCESSLIST　

mysql>SHOW FULL PROCESSLIST;Id  User    Host             db            Command    Time  State   Info                   
------  ------  ---------------  ------------  -------  ------  ------  -----------------------1  root    localhost:61316  laravel_blog  Query         0  (NULL)  show FULL processlist  2  root    localhost:61319  (NULL)        Sleep        94          (NULL)

对于一个连接，或者说一个线程，任何时刻都有一个状态，该状态表示了MySQL当前正在做什么。

2.查询缓存

-- 查看缓存是否开启 （query_cache_type 为 ON 表示已经开启
mysql> show variables like '%query_cache%'; +------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 20971520 |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

检查sql是否命中缓存。命中则检查一次用户权限后返回，这个检查是通过一个对大小写敏感的哈希查找实现的。两次查询只要有一个字节的不同就会失败。否则将进入下一个阶段。

当sql中有不确定的数据时，则不会被缓存。例如用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，其查询结果都不会被缓存。

3.查询优化

语法解析器和预处理

　　　　　　MySQL通过关键字将sql语句进行解析，并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和解析。比如sql中是否使用了错误的关键字或者关键字的顺序是否正确等。预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等。

查询优化器

经过前面的步骤生成的语法树被认为是合法的了，并且由优化器将其转化成查询计划。多数情况下，一条查询可以有很多种执行方式，最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。

MySQL使用基于成本的优化器，通过计算成本选择其中最小的一个。通过SHOW STATUS LIKE 'Last_query_cost';查看成本。成本的最小单位是随机读取一个4K数据页的成本。

MySQL的查询优化器是一个非常复杂的部件，它使用了非常多的优化策略来生成一个最优的执行计划：

- - 重新定义关联表的顺序
  - 将外连接转化成内连接
  - 使用等价变换规则
  - 优化count（）、min（）、max（）
  - 预估并转化为常数表达式
  - 覆盖索引描述
  - 子查询优化
  - 提前终止查询
  - 等值传播
  - 列表IN（）的比较

上面列举了一些，随着MySQL的不断发展，优化器使用的优化策略也在不断的进化。　

查询执行引擎

在完成解析和优化阶段以后，MySQL会生成对应的执行计划，查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成，这些接口被称为handler API。

查询过程中的每一张表由一个handler实例表示。实际上，MySQL在查询优化阶段就为每一张表创建了一个handler实例，优化器可以根据这些实例的接口来获取表的相关信息，包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能，但其底层仅有几十个接口，这些接口像搭积木一样完成了一次查询的大部分操作。

返回结果

查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据，MySQL仍然会返回这个查询的相关信息，比如该查询影响到的行数以及执行时间等。

如果查询缓存被打开且这个查询可以被缓存，MySQL也会将结果存放到缓存中。

结果集返回客户端是一个增量且逐步返回的过程。有可能MySQL在生成第一条结果时，就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存，也可以让客户端第一时间获得返回结果。需要注意的是，结果集中的每一行都会以一个满足①中所描述的通信协议的数据包发送，再通过TCP协议进行传输，在传输过程中，可能对MySQL的数据包进行缓存然后批量发送。

以上内容希望帮助到大家，很多PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家，需要戳这里PHP进阶架构师>>>视频、面试文档免费获取

或者关注我每天分享技术文章

PHP架构师之路www.zhihu.com