SQL语句性能分析

1. 数据库服务器的优化步骤

当我们遇到数据库调优问题的时候，该如何思考呢？这里把思考的流程整理成下面这张图。

整个流程划分成了 观察（Show status） 和 行动（Action） 两个部分。字母 S 的部分代表观察（会使用相应的分析工具），字母 A 代表的部分是行动（对应分析可以采取的行动）。

主要的优化手段：

1. 加缓存，例如redis
2. 调整服务器参数
3. 索引的设计优化，SQL语句是否使用到索引？
4. 读写，主从分离，分库分表（垂直分库，垂直分表，水平分表）

2. 系统参数

在MySQL中，可以使用 SHOW STATUS 语句查询一些MySQL数据库服务器的 性能参数 、 执行频率 。SHOW STATUS语句语法如下：

SHOW [GLOBAL|SESSION] STATUS LIKE '参数';

global：全局
session：当前会话

一些常用的性能参数如下：

1. Connections：连接MySQL服务器的次数。
2. Uptime：MySQL服务器的上线时间。
3. Slow_queries：慢查询的次数。
4. Innodb_rows_read：Select查询返回的行数
5. Innodb_rows_inserted：执行INSERT操作插入的行数
6. Innodb_rows_updated：执行UPDATE操作更新的行数
7. Innodb_rows_deleted：执行DELETE操作删除的行数
8. Com_select：查询操作的次数。
9. Com_insert：插入操作的次数。对于批量插入的 INSERT 操作，只累加一次。
10. Com_update：更新操作的次数。
11. Com_delete：删除操作的次数。

show status like 'last_query_cost'查询最近一次查询涉及到的页数

3. 慢查询日志

具体允许时长超过long_query_time值的sql会被记录到慢查询日志中，默认为10，注意不包含10秒，需要超过10秒才会被记录到慢查询日志中

默认情况下是不开启慢查询日志的，需要手动打开

show variables like '%slow_query_log'

开启慢查询日志：

set global slow_query_log='ON';

查看慢日志文件位置

show variables like '%slow_query_log%'

查询慢查询的时间阈值

show variables like '%long_query_time%';

设置慢查询阈值
set global long_query_time = 1;

设置global的方式对当前session的long_query_time失效。对新连接的客户端有效。所以可以一并执行下述语句

set global long_query_time = 1;
set long_query_time = 1;

mysql服务器重启后，设置的慢查询时间阈值就会失效，可以通过配置文件的方式进行永久设置

slow_query_log=ON
slow_query_log_file=/var/lib/mysql/xxxx-slow.log
long_query_time=1
log_output=FILE

如果不指定存储路径，则默认将慢查询日志存储到mysql数据库的数据文件夹下，不指定文件名的话，默认文件名为hostname-slow.log

查看慢查询数目
SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4. 定位慢sql

4.1 开启慢查询日子

set global slow_query_log='ON';

4.2 设置慢查询阈值

set global long_query_time = 1;

4.3 查看慢查询数目

查询当前系统中有多少条慢查询记录
SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4.4 min_examined_row_limit

除了 long_query_time外，控制慢查询日志的还有一个系统变量：min_examined_row_limit。这个变量的意思是，查询扫描过的最少记录数。这个变量和查询执行时间共同组成了判别一个查询是否是慢查询的条件，如果查询扫描过的记录数大于等于这个变量的值，并且查询执行时间超过了 long_query_time的值，那么这个查询就被记录到慢查询日志中，反之，则不会被记录到慢查询日志中

这个值默认是0，可以通过set命令来修改或者修改my.ini文件来进行修改

4.5 具体分析

以上表所示，数据量4000000。

执行两条sql，查询时长在1s以上

现在我们的慢sql有5条了（之前有过别的操作增加了慢sql数量）

4.6 慢查询日志分析工具：mysqldumpslow

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具 mysqldumpslow 。

查看mysqldumpslow的帮助信息 mysqldumpslow --help

mysqldumpslow 命令的具体参数如下：
-a: 不将数字抽象成N，字符串抽象成S （不加-a，参数就会以N和S替代）
-s: 是表示按照何种方式排序：
c: 访问次数
l: 锁定时间
r: 返回记录
t: 查询时间
al:平均锁定时间
ar:平均返回记录数
at:平均查询时间 （默认方式）
ac:平均查询次数
-t: 即为返回前面多少条的数据；
6 rows in set (2.39 sec)
show status like ‘slow_queries’;
mysqldumpslow --help
-g: 后边搭配一个正则匹配模式，大小写不敏感的；

常用举例：

#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log
#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/atguigu-slow.log
#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/atguigu-slow.log
#另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more

分析慢日志

mysqldumpslow -s -t -t 10 /var/lib/mysql/master-slow.log

可以观察到我们的慢sql语句，整个顺序是按照耗时降序的

开发中，尽量不打开慢查询日志，会耗费一些性能

如何删除慢查询日志文件 rm命令进行删除

如何重置慢查询日志文件？mysqladmin -uroot -p flush-logs slow

注意：mysqladmin -uroot -p flush-logs 如果不加slow，是重置所有日志文件，包括redo，undo等等。

5 explain

定位了慢查询日志后，我们可以通过explain或describe工具对SQL语句进行分析。
describe的使用方法与explain一样，并且分析结果也是一样。

mysql中会为查询语句提供它认为最优的执行计划，但是并不一定是最优的

版本情况
MySQL 5.6.3以前只能 EXPLAIN SELECT ；MYSQL 5.6.3以后就可以 EXPLAIN SELECT，UPDATE，DELETE

在5.7以前的版本中，想要显示 partitions 需要使用 explain partitions 命令；想要显示filtered 需要使用 explain extended 命令。在5.7版本后，默认explain直接显示partitions和filtered中的信息。

5.1 语法

EXPLAIN 或 DESCRIBE语句的语法形式如下：

EXPLAIN SELECT select_options
DESCRIBE SELECT select_options

例如


explain的具体各个结果的意义

5.2 explain各列作用

准备表结构与数据：每张表含10000条数据

5.2.1 table

table：表名

注意：这里的table的个数不一定是我们sql语句里的个数，还有可能包含临时表等。查询的每一行记录都对应着一个单表，临时表也会对应一个记录。

5.2.2 id

1. 在一个大的查询中，每个select关键字都对应一个id
2. 该语句的唯一标识。如果explain的结果包括多个id值，则数字越大越先执行
3. 而对于相同id的行，则表示从上往下依次执行。
4. id号的每个号码代表一趟独立的查询，一个sql语句查询趟数越少越好

举例：一个select

SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';

两个select

 EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2

虚表的情况

EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

特殊情况：

EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a');

为什么上述sql有两个select，但是id就只有1呢？因为mysql优化器对sql语句进行了重写，原sql复杂度是n*n，优化器给优化为外连接的sql，即2n复杂度。

5.2.3 select_type

5.2.4 partitions

代表分区的命中情况，非分区表，该值为null，一般情况下，查询语句的partitions列都为null

5.2.5 type

1. 性能由好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
2. SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴开发手册要求）

5.2.5.1 system

当表中只有一条记录，并且该表使用的存储引擎的统计数据是精确的，比如 MyISAM，Memory，那么对该表访问方法就是system

CREATE TABLE t(i int) Engine=MyISAM;

INSERT INTO t VALUES(1);

EXPLAIN SELECT * FROM t;

5.2.5.2 const

当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是 const

EXPLAIN SELECT * FROM s1 WHERE id = 10005;

5.2.5.3 eq_ref

在连接查询时，如果被驱动表时通过主键或者唯一二级索引列等值匹配的方式进行访问的（如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较），则对该被驱动表的访问方法就是eq_ref

EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;

5.2.5.4 ref_or_null

当通过普通的二级索引进行等值匹配查询，该索引列的值也可以是null值时，那么对该表的访问方法就可能是ref_or_null

explain select * from s1 where key1 = 'a' or key1 is null

5.2.5.5 index_merge

在某些场景下，可以使用索引合并的方法来执行查询

explain select * from s1 where key1 = 'a' or key3 = 'a'

但是如果把or换成and

explain select * from s1 where key1 = 'a' and key3 = 'a'

5.2.5.6 unique_subquery

它是针对在一些包含in子查询的查询语句中，如果查询优化器决定将in子查询转为exists子查询，并且子查询可以使用到主键进行等值匹配的话，那么该子查询的type就是unique_subquery

EXPLAIN SELECT * FROM s1 WHERE key2 IN (SELECT id FROM s2 where s1.key1 =
s2.key1) OR key3 = 'a';

5.2.5.7 range

如果使用索引获取某些范围的记录，那么有可能使用到range

EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');

5.2.5.8 index

当我们可以使用索引覆盖，但是需要扫描全部索引记录时，访问方法就是index

EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';

按照最左匹配原则来看，应该是用不上索引的，但是由于我们查询的列和筛选条件都在联合索引中，所以就用上了索引

例如我们在查询字段中多加一列

EXPLAIN SELECT key1,key_part2 FROM s1 WHERE key_part3 = 'a';

5.2.5.9 all

EXPLAIN SELECT * FROM s1;

5.2.6 key和possible_keys

possible_keys：代表可能用到的索引

key：实际使用的索引

5.2.7 key_len

实际使用到的索引长度（即字节数），值越大越好（主要针对于联合索引）

5.2.8 ref

当使用索引列进行等值查询时，与索引进行等值匹配的对象的信息

select * from s1 where key1 = 'a'

select * from s1 inner join s2 on s1.id = s2.id

select * from s1 inner join s2 on s2.key1 = upper(s1.key1)

5.2.9 rows

预估需要读取的记录的条目数，该值越小越好

SELECT * FROM s1 WHERE key1 > 'z';

5.2.10 filtered

某个表经过搜索条件过滤后剩余记录数的百分比

对于单表查询来说，这个filtered没什么意义，例如

SELECT * FROM s1 WHERE key1 > 'z';

rows是359，filtered是100，那么查询的数据也是359

在连接查询中，驱动表对应的执行计划记录的filtered值，它决定了被驱动表要执行的次数（即 rows*filtered）

SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';

即key1>'z’的rows有359条数据，然后执行and common_field=‘a’时满足的数据量在 359*10%，

5.2.11 Extra

用来说明一些额外信息，包含不适合在其他列中显示，但十分重要的额外信息，我们可以通过这些额外信息来更准确的理解Mysql到底如何执行给定的查询语句。

例如：

5.2.11.1. No Tables used

select 1

5.2.11.2. Impossible WHERE

SELECT * FROM s1 WHERE 1 != 1;

5.2.11.3. Using where

当我们使用全表扫描来执行对某个表的查询，并且该语句的where子句中有针对该表的搜索条件时，在Extra中会提示Using where

SELECT * FROM s1 WHERE common_field = 'a';

5.2.11.4. No matching min/max row

当查询列表处有min或者max聚合函数，但是并没有符合where自居中的搜索条件记录时，就会提示该信息

SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';

那如果不使用函数呢？

SELECT key1 FROM s1 WHERE key1 = 'abcdefg';

5.2.11.5. Using index

当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下，在Extra列将会提示Using index

SELECT key1 FROM s1 WHERE key1 = 'a';

5.2.11.6. Using index condition

有些搜索条件虽然使用到了索引列，但是却不能使用到索引

SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';

如果查询语句中的执行过程将要使用索引下推的特性，则extra会显示Using index condition

5.2.11.7. join buffer

当被驱动表不能有效的利用索引来加快访问速度，mysql会为其分配一块 join buffer的内存块来加快查询速度，也就是基于块的嵌套循环算法

SELECT * FROM s1 INNER JOIN s2 ON s1.common_field = s2.common_field;

5.2.11.8. Using where; Not exists

当我们使用左外连接时，如果where子句中包含要求被驱动表的某个列等于null的搜索条件，但是那个列又是不允许为null的，那么在该表的执行计划的extra列就会提示 not exists

SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS NULL;

5.2.11.9. Using intersect(…) 、 Using union(…) 和 Using sort_union(…)

就是索引合并的意思，

SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';

5.2.11.10. Zero limit

SELECT * FROM s1 LIMIT 0;

5.2.11.11. Using filesort

 SELECT * FROM s1 ORDER BY common_field LIMIT 10;

因为我们的common_field没有索引，但是如果要做排序，则只能读取到内存中进行排序 using filesort。mysql把这种在内存中或者磁盘上进行排序的方式统称为文件排序filesort。

如果列有索引，例如key1

 SELECT * FROM s1 ORDER BY key1 LIMIT 10;

5.2.11.12. Using temporary

使用临时表。在许多查询的执行过程中，mysql可能会借助临时表来完成一些功能，比如去重，排序等，比如许多查询中包含distinct，groupby，union等子句的查询过程中，如果不能有效利用索引来完成查询，mysql很有可能寻求建立内部临时表来执行查询，如果使用到了临时表，则extra会显示using temporary

 SELECT DISTINCT common_field FROM s1;

SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field;

例如有索引的情况下

SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;

5.2.11.14 总结

1. EXPLAIN不考虑各种Cache
2. EXPLAIN不能显示MySQL在执行查询时所作的优化工作
3. EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
4. 部分统计信息是估算的，并非精确值,例如rows

5.3 explain的进一步使用

5.3.1. 传统格式

传统格式简单明了，输出是一个表格形式，概要说明查询计划。

5.3.2 json格式

json提示的信息量会更全面一些。例如查询成本 query_cost

EXPLAIN FORMAT=JSON SELECT ....

 EXPLAIN FORMAT=JSON SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;

{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1013.75"
    },
    "grouping_operation": {
      "using_filesort": false,
      "table": {
        "table_name": "s1",
        "access_type": "index",
        "possible_keys": [
          "idx_key1"
        ],
        "key": "idx_key1",
        "used_key_parts": [
          "key1"
        ],
        "key_length": "303",
        "rows_examined_per_scan": 9895,
        "rows_produced_per_join": 9895,
        "filtered": "100.00",
        "using_index": true,
        "cost_info": {
          "read_cost": "24.25",
          "eval_cost": "989.50",
          "prefix_cost": "1013.75",
          "data_read_per_join": "17M"
        },
        "used_columns": [
          "id",
          "key1"
        ]
      }
    }
  }
}

eval_cost 是这样计算的：
检测 rows × filter 条记录的成本。
prefix_cost 就是单独查询 s1 表的成本，也就是：read_cost + eval_cost
data_read_per_join 表示在此次查询中需要读取的数据量。

如果是针对多表连接查询
被驱动表，可能被读取多次，这里的 read_cost 和 eval_cost 是访问多次被驱动表后累加起来的值，大家主要关注里边儿的 prefix_cost 的值代表的是整个连接查询预计的成本，也就是单次查询驱动表和被驱动表后的成本的和

5.3.3 TREE格式

EXPLAIN FORMAT=tree SELECT ....

TREE格式是8.0.16版本之后引入的新格式，主要根据查询的 各个部分之间的关系和各部分的执行顺序来描述如何查询。

5.4 索引下推

Using index condition

有些搜索条件虽然使用到了索引列，但是却不能使用到索引

SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';

key1>'z’可以使用到索引，但是key1 like '%a’却无法使用到索引，在以前的mysql版本中，是按照如下步骤进行查询

1. 根据key1>'z’来获取满足条件的二级索引记录
2. 根据步骤1的结果得到主键值进行回表
3. 回表中进行like操作

但是like操作也只涉及到了key1列，所以mysql对上述进行了优化

1. 根据key1>'z’获取二级索引
2. 从获取的二级索引来进行like比对过滤（如果有值则回表，如果没有就结束）
3. 回表

mysql将这个改进成为索引下推

如果查询语句中的执行过程将要使用索引下推的特性，则extra会显示Using index condition