1.数据库服务器的优化步骤
2.查看系统性能参数
3.统计SQL的查询成本：last_query_cost
4.定位执行慢的SQL:慢查询日志
得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop100-slow.log
#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/hadoop100-slow.log
#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g “left join” /var/lib/hadoop100-slow.log
#另外建议在使用这些命令时结合 | 和more 使用，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop100-slow.log
- 4.4关闭慢查询日志
- 4.5删除慢查询日志
5.查看SQL执行成本: SHOW PROFILE
6.分析查询语句：EXPLAIN
7.EXPLAIN的进一步使用
- 7.1 EXPLAIN四种输出格式
- 7.2 SHOW WARNINGS的使用
8.分析优化器执行计划：trace
9. MySQL监控分析视图-sys schema

在数据库调优中，我们的目标就是响应时间更快，吞吐量更大。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。

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

当我们遇到数据库调优问题的时候，该如何思考呢?这里把思考的流程整理成下面这张图。
整个流程划分成了观察（Show status）和行动(Action）两个部分。字母S的部分代表观察（会使用相应的分析工具)，字母A代表的部分是行动(对应分析可以采取的行动)。

我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的SQL都有哪些，查看具体的SQL执行计划，甚至是SQL执行中的每一步的成本代价，这样才能定位问题所在，找到了问题，再采取相应的行动。
小结：

2.查看系统性能参数

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

SHOW [ GLOBAL | SESSION ] STATUS LIKE ‘参数”;

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

. Connections:连接MySQL服务器的次数。
. Uptime: MySQL服务器的上线时间。
. Slow_queries:慢查询的次数。
. lnnodb_rows_read : Select查询返回的行数
. lnnodb_rows_inserted:执行INSERT操作插入的行数
lnnodb_rows_updated:执行UPDATE操作更新的行数
lnnodb_rows_deleted:执行DELETE操作删除的行数
. com_select:查询操作的次数。
. Com_insert:插入操作的次数。对于批量插入的INSERT操作，只累加一次。
. com_update:更新操作的次数。
. com_delete:删除操作的次数。

举例1:若查询MySQL服务器的连接次数，则可以执行如下语句:

SHOw STATUS LIKE ‘connections ‘ ;

举例2:若查询服务器工作时间，则可以执行如下语句:

SHow STATUS LIKE ‘ Uptime ‘ ;

3.统计SQL的查询成本：last_query_cost

一条SQL查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择成本最小的一个作为最终执行的执行计划。
如果我们想要查看某条SQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的last_query_cost变量值来得到当前查询的成本。它通常也是我们评价一个查询的执行效率的一个常用指标。这个查询成本对应的是 SQL语句所需要读取的页的数量。
我们依然使用第8章的 student_info 表为例：

CREATE TABLE student_info ( id INT(11) NOT NULL AUTO_INCREMENT, student_id INT NOT NULL , name VARCHAR(20) DEFAULT NULL, course_id INT NOT NULL , class_id INT(11) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

如果我们想要查询 id=900001 的记录，然后看下查询成本，我们可以直接在聚簇索引上进行查找：

SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id = 900001;

运行结果（1 条记录，运行时间为 0.042s ）
然后再看下查询优化器的成本，实际上我们只需要检索一个页即可：

mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+----------+
| Variable_name   | Value   |
+-----------------+----------+
| Last_query_cost | 1.000000 |
+-----------------+----------+

如果我们想要查询 id 在 900001 到 9000100 之间的学生记录呢？

SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id BETWEEN 900001 AND 900100;

运行结果（100 条记录，运行时间为 0.046s ）：
然后再看下查询优化器的成本，这时我们大概需要进行 20 个页的查询。

mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| Last_query_cost | 21.134453 |
+-----------------+-----------+

你能看到页的数量是刚才的 20 倍，但是查询的效率并没有明显的变化，实际上这两个 SQL 查询的时间基本上一样，就是因为采用了顺序读取的方式将页面一次性加载到缓冲池中，然后再进行查找。虽然页数量（last_query_cost）增加了不少，但是通过缓冲池的机制，并没有增加多少查询时间。
使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。

SQL查询是一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论: 1,位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。 2,批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。所以说，遇到/o并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是经常使用的数据就要尽量放到缓冲池中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。

4.定位执行慢的SQL:慢查询日志

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

4.1开启慢查询日志参数

1.开启slow_query_log
在使用之前，我们需要先看下慢查询是否已经开启，使用下面的这条命令即可:

mysql > show variables like '%slow_query_log%';

然后我们再来查看下慢查询日志是否开启，以及慢查询日志文件的位置：

我们能看到slow_query.log=OFF，我们可以把慢查询日志打开，注意设置变量值的时候需要使用global，否则会报错:

set global slow_query_log=on;

然后我们再来查看下慢查询是否开启,以及慢查询日志文件的位置

能看到这时慢查询分析已经开启，同时文件保存在 /var/lib/mysql/hadoop100-slow.log 文件
中。
2.修改long_query_time阈值
接下来查看慢查询的时间阈值设置：

show variables like '%long_query_time';

#测试发现：设置global的方式对当前session的long_query_time失效。对新连接的客户端有效。所以可以一并
执行下述语句
mysql > set global long_query_time = 1; 
mysql> show global variables like '%long_query_time%';
mysql> set long_query_time=1;
mysql> show variables like '%long_query_time%';

4.2 查看慢查询数目

查询当前系统中有多少条慢查询记录

show global status like '%slow_queries%';

1.测试
准备测试数据(400万条数据)

从上面的结果可以看出来，查询学生编号为“3999951”的学生信息花费时间为5.47秒。查询学生姓名为“JnoEfp”的学生信息花费时间为2.35秒。已经达到了秒的数量级，说明目前查询效率是比较低的，下面的小节我们分析一下原因。
2.分析

show status like 'slow_queries';

可以看到,此时慢查询数目已经有两条记录:

4.3 慢查询日志分析工具:mysqldumpslow

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

mysqldumpslow —help

mysqldumpslow 命令的具体参数如下：

-a: 不将数字抽象成N，字符串抽象成S
-s: 是表示按照何种方式排序：
c: 访问次数
l: 锁定时间
r: 返回记录
t: 查询时间
al:平均锁定时间
ar:平均返回记录数
at:平均查询时间（默认方式）
ac:平均查询次数
-t: 即为返回前面多少条的数据；
-g: 后边搭配一个正则匹配模式，大小写不敏感的；

举例：我们想要按照查询时间排序，查看前五条 SQL 语句，这样写即可：

mysqldumpslow -a -s t -t 5 /var/lib/mysql/hadoop100-slow.log

一下查询出的就是上面执行的两条sql，并显示出所执行的时间:

工作常用参考： :::tips

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

:::

4.4关闭慢查询日志

使用SET语句来设置。（1）停止MySQL慢查询日志功能，具体SQL语句如下。

SET GLOBAL slow_query_log=off;

（2）重启MySQL服务，使用SHOW语句查询慢查询日志功能信息,查看慢查询是否关闭，以及恢复long_query_time阈值，具体SQL语句如下

SHOW VARIABLES LIKE '%slow_query_log%';
#以及
SHOW VARIABLES LIKE '%long_query_time%';

4.5删除慢查询日志

使用SHOw语句显示慢查询日志信息，具体SQL语句如下。

SHOW VARIABLES LIKE '%slow_query_log%';

从执行结果可以看出，慢查询日志的目录默认为MysQL的数据目录，在该目录下手动删除慢查询日志文件即可。使用命令 mysqladmin flush-logs 来重新生成查询日志文件，具体命令如下，执行完毕会在数据目录下重新生成慢查询日志文件。(执行该命令时要保证 slow_query_log是on开启状态)：set global slow_query_log=on; :::tips mysqladmin -uroot -p flush-logs slow :::

提示慢查询日志都是使用mysqladmin flush-logs命令来删除重建的。使用时一定要注意，一旦执行了这个命令，慢查询日志都只存在新的日志文件中，如果需要旧的查询日志，就必须事先备份。

5.查看SQL执行成本: SHOW PROFILE

show profile在<逻辑架构>章节中讲过,这里作为复习
Show Profile是MysQL提供的可以用来分析当前会话中SQL都做了什么、执行的资源消耗情况的工具，可用于sql调优的测量。默认情况下处于关闭状态，并保存最近15次的运行结果。
我们可以在会话级别开启这个功能

show variables like 'profiling';

通过设置 profiling=’’ON” 来开启show profile

 set profiling ='on';

然后执行相关的查询语句。接下来看下当前会话都有哪些profiles,使用下面的命令：

show profiles;

能看到当前会话一共有2个查询，如果想要看最近一次的查询，则执行：

show profile;

我们也可以查看指定的Query lD的开销，比如 show profile for query 2查询结果是一样的。在SHOwPROFILE中我们可以查看不同部分的开销，比如cpu、block.io等:

how profile cpu,block io for query 6;

通过上面的结果，我们可以弄清楚每一步骤的耗时，以及在不同位置，比如cpu,block io的执行时间，这样我们可以判断出来SQL到底慢在哪里
show profile的常用查询参数：
① ALL：显示所有的开销信息。
② BLOCK IO：显示块IO开销。
③ CONTEXT SWITCHES：上下文切换开销。
④ CPU：显示CPU开销信息。
⑤ IPC：显示发送和接收开销信息。
⑥ MEMORY：显示内存开销信息。
⑦ PAGE FAULTS：显示页面错误开销信息。
⑧ SOURCE：显示和Source_function，Source_file，Source_line相关的开销信息。
⑨ SWAPS：显示交换次数开销信息。

6.分析查询语句：EXPLAIN

6.1 概述

定位了查询慢的SQL之后，我们就可以使用EXPLAIN或DESCRIBE 工具做针对性的分析查询语句。DESCRIBE语句的使用方法与EXPLAIN语句是一样的，并且分析结果也是一样的。
MySQL中有专门负责优化SELECT语句的优化器模块，主要功能:通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间)。
这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，大家看懂EXPLAIN语句的各个输出项，可以有针对性的提升我们查询语句的性能。
1.能做什么?

表的读取顺序
数据读取操作的操作类型
哪些索引可以使用
哪些索引被实际使用
表之间的引用
每张表有多少行被优化器查询
6.2 基本语法
EXPLAIN或DESCRIBE语句的语法形式如下:
```
EXPLAIN SELECT 字段名;
或者
DESCRIBLE SELECT 字段名
```
如果我们想看看某个查询的执行计划的话，可以在具体的查询语句前边加一个EXPLAIN，就像这样:
```
EXPLAIN SELECT 1;
```

输出的上述信息就是所谓的执行计划。在这个执行计划的辅助下，我们需要知道应该怎样改进自己的查询语句以使查询执行起来更高效。其实除了以SELECT开头的查询语句，其余的DELETE、INSERT、REPLACE以及UPDATE语句等都可以加上 EXPLAIN，用来查看这些语句的执行计划，只是平时我们对SELECT语句更感兴趣。注意:执行EXPLAIN时并没有真正的执行该后面的语句，因此可以安全的查看执行计划。
EXPLAIN语句输出的各个列的作用如下:

6.3 数据准备

1.建表

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_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;

2. 创建函数

DELIMITER //
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 //
DELIMITER ;

3. 设置参数 log_bin_trust_function_creators
创建函数，假如报错，需开启如下命令：允许创建函数设置：

set global log_bin_trust_function_creators=1;    # 不加global只是当前窗口有效。

4.创建存储过程

DELIMITER //
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 //
DELIMITER ;

DELIMITER //
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 //
DELIMITER ;

5.调用存储过程
s1表数据的添加：加入1万条记录：
s2表数据的添加：加入1万条记录：

CALL insert_s1(10001,10000);
CALL insert_s2(10001,10000);

6.4 EXPLAIN各列的作用

table

不论我们的查询语句有多复杂，里边儿包含了多少个表，到最后也是需要对每个表进行单表访问的，所以MySQL规定EXPLAIN语句输出的每条记录都对应着某个单表的访问方法，该条记录的table列代表着该表的表名(有时不是真实的表名字，可能是简称)，查询的每一行记录都对应着一个单表。

此处的 s1表示驱动表，s2表示被驱动表

EXPLAIN SELECT FROM s1 INNER JOIN *s2;

在一个大的查询语句中每个SELECT关键字都对应一个唯一的id，id号每个号码，表示一趟独立的查询如：

1.mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = ‘a’;

2.mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2;

3.EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = ‘a’;

4.EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = ‘a’);

查询优化器可能对涉及子查询的查询语句进行重写转变为多表查询的操作所以这里的id只有1

5.EXPLAIN SELECT FROM s1 UNION SELECT FROM s2;

由于UNION是不去重的，所有以产生一个额外的临时表

6.EXPLAIN SELECT FROM s1 UNION ALL SELECT FROM s2;

小结：

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

select_type

一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表（这些表用来做连接查询)，每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。
MySQL为每一个SELECT类键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色，我们看一下
select_type都能取哪些值，请看官方文档:

SIMPLE

查询语句中不包含`UNION或者**子查询**的查询都算作是SIMPLE类型 :::tips EXPLAIN SELECT * FROM s1; ::: 连接查询也算是SIMPLE`类型 :::tips EXPLAIN SELECT * FROM s1 INNER JOIN s2; :::

PRIMARY

对于包含**UNION**或者**UNION ALL**或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个查询的select_type值就是**PRIMARY* :::tips EXPLAIN SELECT FROM s1 UNION SELECT * FROM s2; :::

UNION

对于包含UNION或者**UNION ALL**的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询以外，其余的小查询的select_type值就是**UNION** :::tips EXPLAIN SELECT FROM s1 UNION SELECT FROM s2; :::

UNION RESULT

1.MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的查询的select_type就是UNION RESULT` :::tips EXPLAIN SELECT FROM s1 UNION SELECT FROM s2; :::
2.如果使用的是union all来完成查询工作，不需要去重，也就不会产生临时表

SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是不相关子查询。该子查询的第一个SELECT关键字代表的那个查询的select_type就是**SUBQUERY** :::tips EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = ‘a’; :::

DEPENDENT SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是相关子查询，
则该子查询的第一个SELECT关键字代表的那个查询的select_type就是DEPENDENT SUBQUERY :::tips EXPLAIN SELECT * FROM s1
WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = ‘a’; :::

DEPENDENT UNION

在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了
#最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION。 :::tips EXPLAIN SELECT * FROM s1
WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = ‘a’ UNION SELECT key1 FROM s1 WHERE key1 = ‘b’); :::

DERIVED

对于包含派生表的查询，该派生表对应的子查询的select_type就是DERIVED :::tips EXPLAIN SELECT
FROM (SELECT key1, COUNT() AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1; :::

4.type
执行计划的一条记录就代表着MySQL对某个表的执行查询时的访问方法，又称”访问类型”，其中的type列就表明了这个访问方法是啥，是较为重要的一个指标。比如，看到type列的值是ref，表明MySQL即将使用ref访问方法来执行对s1表的查询。
完整的访问方法如下: system, const, eq_ref，ref，fulltext , ref_or_null, index_merge , unique_subquery , ndex_subquery , range , index,ALL。
结果值从最好到最坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range > index > ALL
其中比较重要的几个提取出来（见上图中的蓝色）。SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴开发手册要求）
5.possible_keys和key
在EXPLAIN语句输出的执行计划中，possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些。一般查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。key列表示实际用到的索引有哪些，如果为NULL，则没有使用索引。
6.key_len ☆
实际使用到的索引长度(即：字节数)，帮你检查是否充分的利用上了索引，值越大越好,主要针对于联合索引，有一定的参考意义。
key_len的长度计算公式： :::tips 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) ::: 7.rows
预估的需要读取的记录条数，值越小越好
8.filtered
某个表经过搜索条件过滤后剩余记录条数的百分比
10.Extra ☆
顾名思义，Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询句。MySQL提供的额外信息有好几十个，我们就不一个一个介绍了，所以我们只挑比较重要的额外信息介绍给大家。

7.EXPLAIN的进一步使用

7.1 EXPLAIN四种输出格式

这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式， JSON格式， TREE格式以及可视化输出。用户可以根据需要选择适用于自己的格式。
1.传统格式
传统格式简单明了，输出是一个表格形式，概要说明查询计划。 :::tips mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.common_field IS NOT NULL; :::
2.JSON格式
第1种格式中介绍的EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性―-成本。而JSON格式是四种格式里面输出信息最详尽的格式，里面包含了执行的成本信息。

SON格式：在EXPLAIN单词和真正的查询语句中间加上 FORMAT=JSON 。 :::tips EXPLAIN FORMAT=JSON SELECT …. :::
EXPLAIN 的Column与JSON的对应关系:(来源于MySQL 5.7文档)

这样我们就可以得到一个json格式的执行计划，里面包含该计划花费的成本，比如这样: :::tips mysq1> EXPLAIN FORMAT=JSON SELECT FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = ‘a’\G :::
3.TREE格式
TREE格式是8.0.16版本之后引入的新格式，主要根据查询的 各个部分之间的关系 和 各部分的执行顺序 来描述如何查询。
*4. 可视化输出
可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图标，即可生成可视化的查询计划。上图按从左到右的连接顺序显示表。红色框表示全表扫描，而绿色框表示使用索引查找。对于每个表，显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表的成本。

7.2 SHOW WARNINGS的使用

在我们使用EXPLAIN语句查看了某个查询的执行计划后，紧接着还可以使用SHOW WARNINGS语句查看与这个查询的执行计划有关的一些扩展信息，比如这样: :::tips mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.common_field IS NOT NULL; :::

大家可以看到 SHOW WARNINGS展示出来的信息有三个字段，分别是Level、Code、Message。我们最常见的就是Code为1003的信息，当Code值为1003时，Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上边的查询本来是一个左(外）连接查询，但是有一个s2.common_field IS NOT NULL的条件，这就会导致查询优化器把左（外）连接查询优化为内连接查询，从SHOW WARNINGS的Message字段也可以看出来，原本的LEFT JOIN已经变成了JOIN。

8.分析优化器执行计划：trace

OPTIMIZER_TRACE 是MySQL 5.6引入的一项跟踪功能，它可以跟踪优化器做出的各种决策（比如访问表的方法、各种开销计算、各种转换等），并将跟踪结果记录到INFORMATION_SCHEMA.OPTIMIZER_TRACE表中。
此功能默认关闭。开启trace，并设置格式为JSON，同时设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

第09_性能分析工具的使用