慢查询 MySQL 定位优化技巧，从10s优化到300ms

以你之姓@ 2023-10-02 21:29 48阅读 0赞

今天分享一下如何快速定位慢查询SQL以及优化

### 1.如何定位并优化慢查询SQL？ ###

一般有3个思考方向：

1.  根据慢日志定位慢查询sql
2.  使用explain等工具分析sql执行计划
3.  修改sql或者尽量让sql走索引

### 2.如何使用慢查询日志？ ###

先给出步骤，后面说明，有3个步骤

#### 1. 开启慢查询日志 ####

首先开启慢查询日志，由参数`slow_query_log`决定是否开启，在MySQL命令行下输入下面的命令：

set global slow_query_log=on;

默认环境下，慢查询日志是关闭的，所以这里开启。

#### 2. 设置慢查询阈值 ####

set global long_query_time=1;

只要你的SQL实际执行时间超过了这个阈值，就会被记录到慢查询日志里面。这个阈值默认是10s，线上业务一般建议把`long_query_time`设置为1s，如果某个业务的MySQL要求比较高的QPS，可设置慢查询为0.1s。

发现慢查询及时优化或者提醒开发改写。一般测试环境建议`long_query_time`设置的阀值比生产环境的小，比如生产环境是1s，则测试环境建议配置成0.5s。便于在测试环境及时发现一些效率的SQL。

甚至某些重要业务测试环境`long_query_time`可以设置为0，以便记录所有语句。并留意慢查询日志的输出，上线前的功能测试完成后，分析慢查询日志每类语句的输出，重点关注`Rows_examined`（语句执行期间从存储引擎读取的行数），提前优化。

#### 3.确定慢查询日志的文件名和路径 ####

show global variables like 'slow_query_log_file'

![2a65eaa9c41f04948eb6c2a21e173249.png][]

结果会发现慢日志默认路径就是MySQL的数据目录，我们可以来看一下MySQL数据目录

show global variables like 'datadir';

![f1b00802efdbde3ad7bc9099bf65be1a.png][]

不用关注这里为什么不是MySQL 8.0，这和版本没什么关系的。

来，直接上菜，干巴巴的定义我自己都看不下去

我们先来查看一下变量，我框出了需要注意的点

查询带有quer的相关变量

show global variables like '%quer%';

![1534876a9b2d63adb5bde075cca4617d.png][]

![a159c349d48dbe54f107ae409004e1e5.png][]

这里设置慢查询阈值为1s

set global long_query_time=1;

可以看到已经修改过来了

![a5dcb669c1d683c2cdef031b2c57e241.png][]

但是重启mysql客户端设置和统计慢查询日志条数就会清零，即所有配置修改会还原

命令修改配置之后，在命令行`net stop mysql`关闭MySQL服务，再`net start mysql`开启MySQL服务，接着执行`show global variables like '%quer%';`会发现配置还原了。

在配置文件修改才能永久改变，否则重启数据库就还原了

### 3.慢查询例子演示，新手都能看懂 ###

数据表结构，偷懒没写comment

CREATE TABLE `person_info_large` (  
        `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,  
        `account` VARCHAR (10),   
        `name` VARCHAR (20),  
        `area` VARCHAR (20),  
        `title` VARCHAR (20), 
        `motto` VARCHAR (50),
        PRIMARY KEY (`id`),  
        UNIQUE(`account`),
        KEY `index_area_title`(`area`,`title`) 
    ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8

这里的数据是200W条。请注意表结构，记住哪几个字段有索引即可，后续围绕这个表进行分析。

![c075bdad03b0e14141aeda16fcf5b940.png][]

这个3.36s并不是实际执行时间，实际执行时间得去慢查询日志去看`Query_time`参数

![0b95685a38f3e07d0d593e62afdf3d1b.png][]

可以看到`Query_time: 6.337729s`，超过了1s，所以会被记录，一个select语句查询这么久，简直无法忍受。

图中其他的参数解释如下：

*  Time：慢查询发生的时间
 *  Query\_time：查询时间
 *  Lock\_time：等待锁表的时间
 *  Rows\_sent：语句返回的行数
 *  Rows\_exanined：语句执行期间从存储引擎读取的行数

上面这种方式是用系统自带的慢查询日志查看的，如果觉得系统自带的慢查询日志不方便查看，可以使用`pt-query-digest`或者`mysqldumpslow`等工具对慢查询日志进行分析。

注意：有的慢查询正在执行，结果已经导致数据库负载过高，而由于慢查询还没执行完，因此慢查询日志看不到任何语句，此时可以使用`show processlist`命令查看正在执行的慢查询。`show processlist`显示哪些线程正在运行，如果有`PROCESS`权限，则可以看到所有线程。否则，只能看到当前会话线程。

### 4.查询语句慢怎么办？explain带你分析sql执行计划 ###

根据上一节的表结构可以知道，account是添加了唯一索引的字段。explain分析一下执行计划。

![777d4a1dec07233ae6093d8944739eaf.png][]

我们重点需要关注`select_type`、`type`、`possible_keys`、`key`、`Extra`这些列，我们来一一说明，看到`select_type`列，这里是`SIMPLE`简单查询，其他值下面给大家列出。

![d1a628b12c75f28b593dd2343be57b3f.png][]

type列，这里是index，表示全索引扫描

![d6b0d97db9bb5fd8aed49ec222612213.png][]

表格从上到下代表了sql查询性能从最优到最差，如果是type类型是all，说明sql语句需要优化。

> “
> 
> 注意：如果`type = NULL`，则表明个MySQL不用访问表或者索引，直接就能得到结果，比如`explain select sum(1+2);`
> 
> ”

`possible_keys`代表可能用到的索引列，key表示实际用到的索引列，以实际用到的索引列为准，这是查询优化器优化过后选择的，然后我们也可以根据实际情况强制使用我们自己的索引列来查询。

Extra列，这里是`Using index`

![788b2db81ff857752b706296e39ba4b0.png][]

一定要注意，Extra中出现`Using filesort`、`Using temporary`代表MySQL根本不能使用索引，效率会受到严重影响，应当尽可能的去优化。

出现`Using filesort`说明MySQL对结果使用一个外部索引排序，而不是从表里按索引次序读到相关内容，有索引就维护了B+树，数据本来就已经排好序了，这说明根本没有用到索引，而是数据读完之后再排序，可能在内存或者磁盘上排序。也有人将MySQL中无法利用索引的排序操作称为“文件排序”。

出现`Using temporary`表示MySQL在对查询结果排序时使用临时表，常见于`order by`和分组查询`group by`

回到上一个话题，我们看到account是添加了唯一索引的字段。explain分析了执行计划后

![153108b62e028dd8543075874afeb70a.png][]

直接按照account降序来查

![da58cb1c0e5b066c1ba2c37ae9486a50.png][]

查看慢查询日志发现，使用索引之后，查询200W条数据的速度快了2s

接着我们分析一下查询name的sql执行计划

![6c7b72ac6c993370fd8a2edb6188d357.png][]

然后给name字段加上索引

![dc48e86b1de2ba86bb06eb32ca3601b0.png][]

加上索引之后，继续看看查询name的sql执行计划

![40d893466189f763ae1636221b88a55b.png][]

对比一下前面name不加索引时的执行计划就会发现，加了索引后，type由ALL全表扫描变成index索引扫描。`order by`并没有 `using filesort`，而是`using index`，这里B+树已经将这个非聚集索引的索引字段的值排好序了，而不是等到查询的时候再去排序。

接着我们继续执行查询语句，此时name已经是添加了索引的。

![27aa589356cc1ed0327a58a4b6550ef0.png][]

结果发现，name添加索引之前，降序查询name是花费6.337729s，添加索引之后，降序查询name花费了3.479827s，原因就是B+树的结果集已经是有序的了。

![24b5650612f8f27d53ea4f66405c74ed.png][]

### 5.当主键索引、唯一索引、普通索引都存在，查询优化器如何选择？ ###

查询一下数据的条数，这里`count(id)`，分析一下sql执行计划

![81ebd358d5495f50004addb4a869a453.png][]

这里实际使用的索引是account唯一索引。

分析一下：实际使用哪个索引是查询优化器决定的，B+树的叶子结点就是链表结构，遍历链表就可以统计数量，但是这张表，有主键索引、唯一索引、普通索引，优化器选择了account这个唯一索引，这肯定不会使用主键索引，因为主键索引是聚集索引，每个叶子包含具体的一个行记录（很多列的数据都在里面），而非聚集索引每个叶子只包含下一个主键索引的指针，很显然叶子结点包含的数据是越少越好，查询优化器就不会选择主键索引

当然，也可以强制使用主键索引，然后分析sql执行计划

![c0771d3f037d8275b47241b9412a8de8.png][]

我们看一下优化器默认使用唯一索引大致执行时间676ms

![cd38bd4af3d47183fac55d7ec4cbf88b.png][]

强制使用主键索引大致执行时间779ms

![d7af0002fd162c537c4f8545d1bbaf9d.png][]

我们可以用`force index`强制指定索引，然后去分析执行计划看看哪个索引是更好的，因为查询优化器选择索引不一定是百分百准确的，具体情况可以根据实际场景分析来确定是否使用查询优化器选择的索引。

[2a65eaa9c41f04948eb6c2a21e173249.png]: https://img-blog.csdnimg.cn/img_convert/2a65eaa9c41f04948eb6c2a21e173249.png
[f1b00802efdbde3ad7bc9099bf65be1a.png]: https://img-blog.csdnimg.cn/img_convert/f1b00802efdbde3ad7bc9099bf65be1a.png
[1534876a9b2d63adb5bde075cca4617d.png]: https://img-blog.csdnimg.cn/img_convert/1534876a9b2d63adb5bde075cca4617d.png
[a159c349d48dbe54f107ae409004e1e5.png]: https://img-blog.csdnimg.cn/img_convert/a159c349d48dbe54f107ae409004e1e5.png
[a5dcb669c1d683c2cdef031b2c57e241.png]: https://img-blog.csdnimg.cn/img_convert/a5dcb669c1d683c2cdef031b2c57e241.png
[c075bdad03b0e14141aeda16fcf5b940.png]: https://img-blog.csdnimg.cn/img_convert/c075bdad03b0e14141aeda16fcf5b940.png
[0b95685a38f3e07d0d593e62afdf3d1b.png]: https://img-blog.csdnimg.cn/img_convert/0b95685a38f3e07d0d593e62afdf3d1b.png
[777d4a1dec07233ae6093d8944739eaf.png]: https://img-blog.csdnimg.cn/img_convert/777d4a1dec07233ae6093d8944739eaf.png
[d1a628b12c75f28b593dd2343be57b3f.png]: https://img-blog.csdnimg.cn/img_convert/d1a628b12c75f28b593dd2343be57b3f.png
[d6b0d97db9bb5fd8aed49ec222612213.png]: https://img-blog.csdnimg.cn/img_convert/d6b0d97db9bb5fd8aed49ec222612213.png
[788b2db81ff857752b706296e39ba4b0.png]: https://img-blog.csdnimg.cn/img_convert/788b2db81ff857752b706296e39ba4b0.png
[153108b62e028dd8543075874afeb70a.png]: https://img-blog.csdnimg.cn/img_convert/153108b62e028dd8543075874afeb70a.png
[da58cb1c0e5b066c1ba2c37ae9486a50.png]: https://img-blog.csdnimg.cn/img_convert/da58cb1c0e5b066c1ba2c37ae9486a50.png
[6c7b72ac6c993370fd8a2edb6188d357.png]: https://img-blog.csdnimg.cn/img_convert/6c7b72ac6c993370fd8a2edb6188d357.png
[dc48e86b1de2ba86bb06eb32ca3601b0.png]: https://img-blog.csdnimg.cn/img_convert/dc48e86b1de2ba86bb06eb32ca3601b0.png
[40d893466189f763ae1636221b88a55b.png]: https://img-blog.csdnimg.cn/img_convert/40d893466189f763ae1636221b88a55b.png
[27aa589356cc1ed0327a58a4b6550ef0.png]: https://img-blog.csdnimg.cn/img_convert/27aa589356cc1ed0327a58a4b6550ef0.png
[24b5650612f8f27d53ea4f66405c74ed.png]: https://img-blog.csdnimg.cn/img_convert/24b5650612f8f27d53ea4f66405c74ed.png
[81ebd358d5495f50004addb4a869a453.png]: https://img-blog.csdnimg.cn/img_convert/81ebd358d5495f50004addb4a869a453.png
[c0771d3f037d8275b47241b9412a8de8.png]: https://img-blog.csdnimg.cn/img_convert/c0771d3f037d8275b47241b9412a8de8.png
[cd38bd4af3d47183fac55d7ec4cbf88b.png]: https://img-blog.csdnimg.cn/img_convert/cd38bd4af3d47183fac55d7ec4cbf88b.png
[d7af0002fd162c537c4f8545d1bbaf9d.png]: https://img-blog.csdnimg.cn/img_convert/d7af0002fd162c537c4f8545d1bbaf9d.png