八股文背的挺好，一问SQL慢查询就歇菜了

如何使用慢查询日志？

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。

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

show global variables like 'slow_query_log_file'

slow_query_log表示慢查询日志是否开启了，用ON和OFF分别表示开启和关闭，设置为 ON 的时候，才会记录慢查询的具体语句和执行时间。

long_query_time表示慢查询的临界值，也就是执行时间超过这个值的，就会记录下来。单位是秒。

slow_query_log_file表示慢查询日志的存储位置，我们最终要靠这个文件记录的内容来分析慢查询语句的。

使用慢查询日志

设置好慢查询日志的存储位置，然后等着看就可以了。

我们前面设置的最大执行时间是1秒，凡是超过一秒的SQL语句都会被记录进来，我们只要定期的查看这个日志，看有哪些慢SQL，对应的找到代码位置，做相应的修改和优化就好了。

下面是我测试的一条慢查询，睡眠3秒中，肯定执行时间是超过1秒了。

SELECT SLEEP(3);

然后打开慢查询日志，看到里面已经有了慢查询日志。

时间戳，表示查询发生的时间。

用户和主机信息为 “root[root] @ localhost [127.0.0.1] Id: 2″，显示了执行查询的用户、主机、IP 地址和连接 ID。

Query_time 为查询执行时间，为 3.002676 秒，Lock_time为锁定时间为 0.000000，表示没有涉及锁定操作。

Rows_sent表示查询结果集的行数。

Rows_examined查询期间的检查行。

最下面是实际的查询语句。

这里只是为了测试，在我们的系统中，实际的查询语句可能是比较复杂的SQL，比如包含子查询、Join的，或者本身涉及的表数据量比较大，而且也没有命中索引。

explain分析一下执行计划，只需要在普通的sql语句之前添加explain关键字即可。

我们重点需要关注select_type、type、possible_keys、key、Extra这些列，我们来一一说明。

看到select_type列，这里是SIMPLE简单查询，其他值下面给大家列出。

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

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

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

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

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

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

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

对比一下前面name不加索引时的执行计划就会发现，加了索引后，type由ALL全表扫描变成index索引扫描。

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

原文始发于微信公众号（程序员阿凯）：八股文背的挺好，一问SQL慢查询就歇菜了

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/174305.html