数据库|MySQL性能分析工具的使用（慢查询日志、EXPLAN的使用、分析优化器执行计划：trace、MySQL监控分析视图-sys schema）数据库|mysql

文章目录

1.数据库服务器的优化步骤
2.查看系统性能参数
- 2.1 语法
- 2.2 常用参数
3.统计SQL的查询成本：last_query_cost
4.定位执行慢的SQL：慢查询日志
- 4.1 慢查询日志的概念
- 4.2 开启慢查询日志
- 4.3 查看慢查询数目
- 4.4 慢查询日志分析工具：mysqldumpslow
- 4.5 关闭慢查询
- - 4.5.1 永久性
  - 4.5.2 临时性
- 4.6 删除慢查询日志
5.查看SQL执行成本
6.分析查询语句：EXPLAN
- 6.1 概述
- 6.2 语法
- 6.3 各列的作用
- - 6.3.1 id
  - 6.3.2 select_type
  - 6.3.3 type
  - 6.3.4 possible_keys和key
  - 6.3.5 key_len
  - 6.3.6 ref
  - 6.3.7 rows
  - 6.3.8 filtered
  - 6.3.9 Extra
- 6.4 代码演示
- 6.5 总结
7.EXPLAN进一步使用
- 7.1 EXPLAIN四种输出格式
- - 7.1.1 传统格式
  - 7.1.2 JSON格式
  - 7.1.2 TREE格式
  - 7.1.3 可视化输出
- 7.2 SHOW WARNINGS的使用
8.分析优化器执行计划：trace
9.MySQL监控分析视图-sys schema

1.数据库服务器的优化步骤整个流程划分成了观察（Show status）和行动（Action）两个部分。字母s的部分代表观察（会使用相应的分析工具），字母A代表的部分是行动（对应分析可以采取的行动）。

数据库|MySQL性能分析工具的使用（慢查询日志、EXPLAN的使用、分析优化器执行计划：trace、MySQL监控分析视图-sys schema）

文章图片

文章图片

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

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

2.2 常用参数

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

3.统计SQL的查询成本：last_query_cost 一条SQL查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择成本最小的一个作为最终执行的执行计划。
【数据库|MySQL性能分析工具的使用（慢查询日志、EXPLAN的使用、分析优化器执行计划：trace、MySQL监控分析视图-sys schema）】如果我们想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的last_query_cost变量值来得到当前查询的成本。它通常也是我们评价一个查询的执行效率的一个常用指标。这个查询成本对应的是SQL语句所需要读取的页的数量。

show status like 'last_query_cost';

4.定位执行慢的SQL：慢查询日志 4.1 慢查询日志的概念 MySQL的慢查询日志，用来记录在MySQL中响应时间超过阈值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上（不含10秒）的语句，认为是超出了我们的最大忍耐时间值。
它的主要作用是，帮助我们发现那些执行时间特别长的SQL查询，并且有针对性地进行优化，从而提高系统的整体效率。当我们的数据库服务器发生阻塞、运行变慢的时候，检查一下慢查询日志，找到那些慢查询，对解决问题很有帮助。比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的sql，结合explain进行全面分析。
默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。
慢查询日志支持将日志记录写入文件。
4.2 开启慢查询日志

开启slow_query_log

#查询慢查询是否已经开启 show variables like '%slow_query_log%'; #修改为开启状态 set global slow_query_log = on

修改long_query_time阈值

#查询阈值 show variables like '%long_query_time%' #修改阈值 set global long_query_time = 1; set session long_query_time = 1;

4.3 查看慢查询数目

show global status like '%Slow_queries%';

4.4 慢查询日志分析工具：mysqldumpslow 在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具mysqldumpslow。
4.5 关闭慢查询 4.5.1 永久性
修改my.cnf或者my.ini文件，把[mysqld]组下的slow_query_log值设置为OFF,修改保存后，再重启MySQL服务，即可生效；

slow_query_log=OFF

或把slow_query_log注释或删除

#slow_query_log=OFF

4.5.2 临时性

set global slow_query_log = OFF

4.6 删除慢查询日志

#显示慢查询日志信息 show variables like 'slow_query_log';

根据目录手动删除慢查询日志文件。

#重新生成新的查询日志文件 mysqladmin -uroot -p flush logs slow

5.查看SQL执行成本 Show Profile是MySQL提供的可以用来分析当前会话中SQL都做了什么、执行的资源消耗情况的工具，可用于sql调优的测量。默认情况下处于关闭状态，并保存最近15次的运行结果。

#查看开启状态 show variables like 'profiling'; #开启 set profiling = 'ON'; #查看全部 show profiles; #查看最近一条 show profile; #查看指定的一条 show profile cpu,block io for query 2;

6.分析查询语句：EXPLAN 6.1 概述

表的读取顺序
数据读取操作的操作类型
哪些索引可以使用
哪些索引被实际使用
表之间的引用
每张表有多少行被优化器查询

6.2 语法

EXPLAIN SELECT select_options #或 DESCRIBE SELECT select_options

6.3 各列的作用

列名	描述
id	在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
select_type	SELECT关键字对应的那个查询的类型
table	表名
`type`	针对单表的访问方法
possible_keys	可能用到的索引
key	实际上使用的索引
`key_len`	实际使用到的索引长度
ref	当使用索引列等值查询时，与索引列进行等值匹配的对象信息
`rows`	预估的需要读取的记录条数
filtered	某个表经过搜索条件过滤后剩余记录条数的百分比
`Extra`	一些额外的信息

6.3.1 id

id如果相同，可以认为时一组，从上往下顺序执行。
在所有组中，id值越大，优先级越高，越先执行。
id每个号码表示一趟独立的查询，一个sql的查询趟数越少越好

6.3.2 select_type
一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表（这些表用来做连接查询），每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。
MySQL为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色。
6.3.3 type
执行计划的一条记录就代表着MySQL对某个表的执行查询时的访问方法，又称“访问类型”，其中的type列就表明了这个访问方法是啥，是较为重要的一个指标。比如，看到type列的值是ref，表明MysQL即将使用ref访问方法来执行对s1表的查询。
完整的访问方法如下：system,const,eq_ref,ref,fulltext,ref_or_null,index_merge,unique_subquery, index_subquery, range, index, ALL。
6.3.4 possible_keys和key
在EXPLAIN语句输出的执行计划中，possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些。一般查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。key列表示实际用到的索引有哪些，如果为NULL，则没有使用索引。
6.3.5 key_len
实际使用到的索引长度(即：字节数)，帮你检查是否充分的利用上了索引，值越大越好,主要针对于联合索引，有一定的参考意义。
6.3.6 ref
当使用索引列等值查询时，与索引列进行等值匹配的对象信息。
比如只是一个常数或者是某个列。
6.3.7 rows
预估的需要读取的记录条数 值越小越好
6.3.8 filtered
某个表经过搜索条件过滤后剩余记录条数的百分比,百分比越高越好。
6.3.9 Extra
Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。

No tables used：当查询语句的没有FROM子句时将会提示该额外信息。
Impossible WHERE：查询语句的WHERE子句永远为FALSE时将会提示该额外信息。
Using where：当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。当使用索引访问来执行对某个表的查询，并且该语句的WHERE子句中有除了该索引包含的列之外的其他搜索条件时，在Extra列中也会提示上述额外信息。
No matching min/max row：当查询列表处有MIN或者MAX聚合函数，但是并没有符合。WHERE子句中的搜索条件的记录时，将会提示该额外信息。
Using index：当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引（不需要回表，数据就在二级索引中）的情况下，在Extra列将会提示该额外信息。
Using index condition：有些搜索条件中虽然出现了索引列，但却不能使用到索引。
Using where; Using join buffer (hash join)：在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join buffer的内存块来加快查询速度，也就是我们所讲的基于块的嵌套循环算法。
Using where; Not exists：当我们使用左（外）连接时，如果WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件，而且那个列又是不允许存储NULL值的，那么在该表的执行计划的Extra列就会提示Not exists额外信息。
Using union(idx_key1,idx_key3); Using where：如果执行计划的Extra列出现了Using intersect(...)提示，说明准备使用Intersect索引合并的方式执行查询，括号中的...表示需要进行索引合并的索引名称；如果出现了Using union(...)提示，说明准备使用Union索引合并的方式执行查询；出现了Using sort_union(...)提示，说明准备使用Sort-Union索引合并的方式执行查询。
Zero limit：当我们的LIMIT子句的参数为0时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息。
Using filesort：如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra列中显示Using filesort提示。
Using temporary：查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行计划的Extra列将会显示Using temporary提示。

6.4 代码演示

#EXPLAN 的使用#创建表 CREATE TABLE s1 ( id INT AUTO_INCREMENT, key1 VARCHAR ( 100 ), key2 INT, key3 VARCHAR ( 100 ), key_part1 VARCHAR ( 100 ), key_part2 VARCHAR ( 100 ), key_part3 VARCHAR ( 100 ), common_field VARCHAR ( 100 ), PRIMARY KEY ( id ), INDEX idx_key1 ( key1 ), UNIQUE INDEX idx_key2 ( key2 ), INDEX idx_key3 ( key3 ), INDEX idx_key_part ( key_part1, key_part2, key_part3 ) )ENGINE = INNODB CHARSET = utf8; CREATE TABLE s2 ( id INT AUTO_INCREMENT, key1 VARCHAR ( 100 ), key2 INT, key3 VARCHAR ( 100 ), key_part1 VARCHAR ( 100 ), key_part2 VARCHAR ( 100 ), key_part3 VARCHAR ( 100 ), common_field VARCHAR ( 100 ), PRIMARY KEY ( id ), INDEX idx_keyl ( key1 ), UNIQUE INDEX idx_key2 ( key2 ), INDEX idx_key3 ( key3 ), INDEX idx_key_part ( key_part1, key_part2, key_part3 ) )ENGINE = INNODB CHARSET = utf8; #返回随机字符串函数 set global log_bin_trust_function_creators=1; CREATE FUNCTION rand_string1 ( n INT ) RETURNS VARCHAR( 255) #该函数会返回一个字符串 BEGIN DECLARE chars_str VARCHAR ( 100 ) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ' ; DECLARE return_str VARCHAR ( 255 ) DEFAULT ''; DECLARE i INT DEFAULT 0; WHILE i < n DO SET return_str = CONCAT( return_str, SUBSTRING( chars_str, FLOOR ( 1+RAND () * 52 ), 1 )); SET i = i + 1; END WHILE; RETURN return_str; END; call() #为表s1添加数据 CREATE PROCEDURE insert_s1 (IN min_num INT (10),IN max_num INT (10)) BEGIN DECLARE i INT DEFAULT 0; SET autocommit = 0; REPEAT SET i = i + 1; INSERT INTO S1 VALUES( (min_num + i), rand_string1(6), (min_num + 30 * i + 5), rand_string1(6), rand_string1(10), rand_string1(5), rand_string1(10), rand_string1(10)); UNTIL i = max_num END REPEAT; COMMIT; END; #为表s2添加数据 CREATE PROCEDURE insert_s2 (IN min_num INT (10),IN max_num INT (10)) BEGIN DECLARE i INT DEFAULT 0; SET autocommit = 0; REPEAT SET i = i + 1; INSERT INTO s2 VALUES( (min_num + i), rand_string1(6), (min_num +30 *i +5), rand_string1(6), rand_string1(10), rand_string1(5), rand_string1(10), rand_string1(10)); UNTIL i = max_num END REPEAT; COMMIT; END; #调用存储过程添加数据 CALL insert_s1(10001,10000); CALL insert_s2(10001,10000); #查看数据是否添加完成 SELECT COUNT(*) FROM s1; SELECT COUNT(*) FROM s2; #1. table：表名 #查询的每一行记录都对应着一个单表 EXPLAIN SELECT * FROM s1; #s1:驱动表s2:被驱动表 EXPLAIN SELECT * FROM s1 INNER JOIN s2; #2. id：在一个大的查询语句中每个SELECT关键字都对应一个唯一的id SELECT * FROM s1 WHERE key1 = 'a'; SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a'; SELECT * FROM s1 WHERE key1 IN (SELECT key3 FROM s2); SELECT * FROM s1 UNION SELECT * FROM s2; EXPLAIN SELECT * FROM s1 WHERE key1 = 'a'; EXPLAIN SELECT * FROM s1 INNER JOIN s2; EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a'; ######查询优化器可能对涉及子查询的查询语句进行重写,转变为多表查询的操作######## EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a'); #Union去重 EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2; EXPLAIN SELECT * FROM s1UNION ALL SELECT * FROM s2; #3. select_type：SELECT关键字对应的那个查询的类型,确定小查询在整个大查询中扮演了一个什么角色 # 查询语句中不包含`UNION`或者子查询的查询都算作是`SIMPLE`类型 EXPLAIN SELECT * FROM s1; #连接查询也算是`SIMPLE`类型 EXPLAIN SELECT * FROM s1 INNER JOIN s2; #对于包含`UNION`或者`UNION ALL`或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个 #查询的`select_type`值就是`PRIMARY` #对于包含`UNION`或者`UNION ALL`的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询 #以外，其余的小查询的`select_type`值就是`UNION` #`MySQL`选择使用临时表来完成`UNION`查询的去重工作，针对该临时表的查询的`select_type`就是 #`UNION RESULT` EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2; EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2; #子查询： #如果包含子查询的查询语句不能够转为对应的`semi-join`的形式，并且该子查询是不相关子查询。 #该子查询的第一个`SELECT`关键字代表的那个查询的`select_type`就是`SUBQUERY` EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a'; #如果包含子查询的查询语句不能够转为对应的`semi-join`的形式，并且该子查询是相关子查询， #则该子查询的第一个`SELECT`关键字代表的那个查询的`select_type`就是`DEPENDENT SUBQUERY` EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = 'a'; #注意的是，select_type为`DEPENDENT SUBQUERY`的查询可能会被执行多次。 #在包含`UNION`或者`UNION ALL`的大查询中，如果各个小查询都依赖于外层查询的话，那除了 #最左边的那个小查询之外，其余的小查询的`select_type`的值就是`DEPENDENT UNION`。 EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = 'a' UNION SELECT key1 FROM s1 WHERE key1 = 'b'); #对于包含`派生表`的查询，该派生表对应的子查询的`select_type`就是`DERIVED` EXPLAIN SELECT * FROM (SELECT key1, COUNT(*) AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1; #当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时， #该子查询对应的`select_type`属性就是`MATERIALIZED` EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2); #子查询被转为了物化表 # 4. partition(略)：匹配的分区信息 # 5. type：针对单表的访问方法 #当表中`只有一条记录`并且该表使用的存储引擎的统计数据是精确的，比如MyISAM、Memory， #那么对该表的访问方法就是`system`。 CREATE TABLE t(i INT) ENGINE=MYISAM; INSERT INTO t VALUES(1); EXPLAIN SELECT * FROM t; #换成InnoDB CREATE TABLE tt(i INT) ENGINE=INNODB; INSERT INTO tt VALUES(1); EXPLAIN SELECT * FROM tt; #当我们根据主键或者唯一二级索引列与常数进行等值匹配时，对单表的访问方法就是`const` EXPLAIN SELECT * FROM s1 WHERE id = 10005; EXPLAIN SELECT * FROM s1 WHERE key2 = 10066; #在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的 #（如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较），则 #对该被驱动表的访问方法就是`eq_ref` EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id; #当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是`ref` EXPLAIN SELECT * FROM s1 WHERE key1 = 'a'; #当对普通二级索引进行等值匹配查询，该索引列的值也可以是`NULL`值时，那么对该表的访问方法 #就可能是`ref_or_null` EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key1 IS NULL; #单表访问方法时在某些场景下可以使用`Intersection`、`Union`、 #`Sort-Union`这三种索引合并的方式来执行查询 EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a'; #`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'; #如果使用索引获取某些`范围区间`的记录，那么就可能使用到`range`访问方法 EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c'); #同上 EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b'; #当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是`index` EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a'; #最熟悉的全表扫描 EXPLAIN SELECT * FROM s1; #6. possible_keys和key：可能用到的索引和实际上使用的索引 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key3 = 'a'; #7.key_len：实际使用到的索引长度(即：字节数) # 帮你检查`是否充分的利用上了索引`，`值越大越好`,主要针对于联合索引，有一定的参考意义。 EXPLAIN SELECT * FROM s1 WHERE id = 10005; EXPLAIN SELECT * FROM s1 WHERE key2 = 10126; EXPLAIN SELECT * FROM s1 WHERE key1 = 'a'; EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a'; EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b'; EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c'; EXPLAIN SELECT * FROM s1 WHERE key_part3 = 'a'; #练习： #varchar(10)变长字段且允许NULL= 10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)+2(变长字段)#varchar(10)变长字段且不允许NULL = 10 * ( character set：utf8=3,gbk=2,latin1=1)+2(变长字段)#char(10)固定字段且允许NULL= 10 * ( character set：utf8=3,gbk=2,latin1=1)+1(NULL)#char(10)固定字段且不允许NULL= 10 * ( character set：utf8=3,gbk=2,latin1=1) # 8. ref：当使用索引列等值查询时，与索引列进行等值匹配的对象信息。 #比如只是一个常数或者是某个列。 EXPLAIN SELECT * FROM s1 WHERE key1 = 'a'; EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id; EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1); # 9. rows：预估的需要读取的记录条数 # `值越小越好` EXPLAIN SELECT * FROM s1 WHERE key1 > 'z'; # 10. filtered: 某个表经过搜索条件过滤后剩余记录条数的百分比 #如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用 #到对应索引的搜索条件外的其他搜索条件的记录有多少条。 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a'; #对于单表查询来说，这个filtered列的值没什么意义，我们`更关注在连接查询 #中驱动表对应的执行计划记录的filtered值`，它决定了被驱动表要执行的次数(即：rows * filtered) EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a'; #11. Extra:一些额外的信息 #更准确的理解MySQL到底将如何执行给定的查询语句 #当查询语句的没有`FROM`子句时将会提示该额外信息 EXPLAIN SELECT 1; #查询语句的`WHERE`子句永远为`FALSE`时将会提示该额外信息 EXPLAIN SELECT * FROM s1 WHERE 1 != 1; #当我们使用全表扫描来执行对某个表的查询，并且该语句的`WHERE` #子句中有针对该表的搜索条件时，在`Extra`列中会提示上述额外信息。 EXPLAIN SELECT * FROM s1 WHERE common_field = 'a'; #当使用索引访问来执行对某个表的查询，并且该语句的`WHERE`子句中 #有除了该索引包含的列之外的其他搜索条件时，在`Extra`列中也会提示上述额外信息。 EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' AND common_field = 'a'; #当查询列表处有`MIN`或者`MAX`聚合函数，但是并没有符合`WHERE`子句中 #的搜索条件的记录时，将会提示该额外信息 EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg'; EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'NlPros'; #NlPros 是 s1表中key1字段真实存在的数据 #select * from s1 limit 10; #当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以 #使用覆盖索引的情况下，在`Extra`列将会提示该额外信息。比方说下边这个查询中只 #需要用到`idx_key1`而不需要回表操作： EXPLAIN SELECT key1,id FROM s1 WHERE key1 = 'a'; #有些搜索条件中虽然出现了索引列，但却不能使用到索引 #看课件理解索引条件下推 EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a'; #在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为 #其分配一块名叫`join buffer`的内存块来加快查询速度，也就是我们所讲的`基于块的嵌套循环算法` #见课件说明 EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field = s2.common_field; #当我们使用左（外）连接时，如果`WHERE`子句中包含要求被驱动表的某个列等于`NULL`值的搜索条件， #而且那个列又是不允许存储`NULL`值的，那么在该表的执行计划的Extra列就会提示`Not exists`额外信息 EXPLAIN SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS NULL; #如果执行计划的`Extra`列出现了`Using intersect(...)`提示，说明准备使用`Intersect`索引 #合并的方式执行查询，括号中的`...`表示需要进行索引合并的索引名称； #如果出现了`Using union(...)`提示，说明准备使用`Union`索引合并的方式执行查询； #出现了`Using sort_union(...)`提示，说明准备使用`Sort-Union`索引合并的方式执行查询。 EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a'; #当我们的`LIMIT`子句的参数为`0`时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息 EXPLAIN SELECT * FROM s1 LIMIT 0; #有一些情况下对结果集中的记录进行排序是可以使用到索引的。 #比如： EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10; #很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候） #进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名：`filesort`）。 #如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的`Extra`列中显示`Using filesort`提示 EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10; #在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们 #在执行许多包含`DISTINCT`、`GROUP BY`、`UNION`等子句的查询过程中，如果不能有效利用索引来完成 #查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行 #计划的`Extra`列将会显示`Using temporary`提示 EXPLAIN SELECT DISTINCT common_field FROM s1; #EXPLAIN SELECT DISTINCT key1 FROM s1; #同上。 EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field; #执行计划中出现`Using temporary`并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以 #我们`最好能使用索引来替代掉使用临时表`。比如：扫描指定的索引idx_key1即可 EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1; #json格式的explain EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a';

6.5 总结

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

7.EXPLAN进一步使用 7.1 EXPLAIN四种输出格式 EXPLAIN可以输出四种格式：传统格式，JSON格式，TREE格式以及可视化输出。
7.1.1 传统格式

文章图片

7.1.2 JSON格式
第1种格式中介绍的EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性——成本。而JSON格式是四种格式里面输出信息最详尽的格式，里面包含了执行的成本信息。

在EXPLAIN单词和真正的查询语句中间加上FORMAT=JSON

EXPLAIN FORMAT=JSON SELECT ....

EXPLAIN的Column与JSON的对应关系

文章图片

7.1.2 TREE格式
主要根据查询的各个部分之间的关系和各部分的执行顺序来描述如何查询。
7.1.3 可视化输出
MySQL Workbench可以进行可视化输出。
7.2 SHOW WARNINGS的使用在我们使用EXPLAIN语句查看了某个查询的执行计划后，紧接着还可以使用SHOW WARNINGS语句查看与这个查询的执行计划有关的一些扩展信息，比如这样：

文章图片

SHOW WARNINGS展示出来的信息有三个字段，分别是Level、Code、MesSaye。最常见的就是Code为1003的信息，当Code值为1003时，Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上边的查询本来是一个左（外）连接查询，但是有一个s2.common_field IS NOT NULL的条件，这就会导致查询优化器把左（外）连接查询优化为内连接查询，从SHOW WARNINGS的Message字段也可以看出来，原本的LEFTJOIN已经变成了JOIN。
8.分析优化器执行计划：trace OPTIMIZER_TRACE是MySQL5.6引入的一项跟踪功能，它可以跟踪优化器做出的各种决策（比如访问表的方法、各种开销计算、各种转换等），并将跟踪结果记录到INFORMATION_SCHEMA.OPTIMIZER_TRACE表中。
此功能默认关闭。开启trace，并设置格式为JsON，同时设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET OPTIMIZER_TRACE="enabled=on",end_markers_in_json=on; SET OPTIMIZER_TRACE_MAX_MEN_SIZE=1000000;

测试执行下面SQL语句：

select * from student where id < 10;

最后，查询information_schema.optimizer_trace 就可以知道MysQL是如何执行sQL的：

select * from information_schema.optimizer_trace

9.MySQL监控分析视图-sys schema 关于MySQL的性能监控和问题诊断，我们一般都从performance_schema中去获取想要的数据，在MySQL5.7.7版本中新增sys schema,它将performance_schema和information_schema中的数据以更容易理解的方式总结归纳为”视图”，其目的就是为了降低查询performance_schema的复杂度，让DBA能够快速的定位问题。下面看看这些库中都有哪些监控表和视图，掌握了这些，在我们开发和运维的过程中就起到了事半功倍的效果。