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

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

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

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

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

详细解释一下这张图:

首先在S1部分，我们需要观察服务器的状态是否存在周期性的波动。如果存在周期性波动，有可能是周期性节点的原因，比如双十一、促销活动等。这样的话，我们可以通过A1这一步骤解决，也就是加缓存，或者更改缓存失效策略。

如果缓存策略没有解决，或者不是周期性波动的原因，我们就需要进一步分析查询延迟和卡顿的原因。接下来进入S2这一步，我们需要开启慢查询。慢查询可以帮我们定X位执行慢的sQL语句。我们可以通过设置long_query_time参数定义"慢"的阈值，如果SQL执行时间超过了long_query_time，则会认为是慢查询。当收集上来这些慢查询之后，我们就可以通过分析工具对慢查询日志进行分析。

在S3这一步骤中，我们就知道了执行慢的SQL，这样就可以针对性地用 EXPLAIN查看对应SQL语句的执行计划，或者使用show profile查看SQL中每一个步骤的时间成本。这样我们就可以了解SQL查询慢是因为执行时间长，还是等待时间长。

2. 查看系统性能参数

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

SHOW STATUS语句语法如下：

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

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

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：删除操作的次数。
若查询MySQL服务器的连接次数，则可以执行如下语句:
```
SHOW STATUS LIKE 'Connections';
```
若查询服务器已经工作的时间，则可以执行如下语句:
```
SHOW STATUS LIKE 'Uptime';
```
若查询MySQL服务器的慢查询次数，则可以执行如下语句:
```
SHOW STATUS LIKE 'Slow_queries';
```
慢查询次数参数可以结合慢查询日志先找出慢查询语句，然后针对慢查询语句进行表结构优化或者查询语句优化。再比如，如下的指令可以查看相关的指令情况:
```
SHOW STATUS LIKE 'Innodb_rows_% ’;
```
分别对应innodb引擎删除行数，插入行数，读取行数，更新函数。

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

一条SQL查询语句在执行前需要确定查询执行计划，如果存在多种执行计划的话，MySQL会计算每个执行计划所需要的成本，从中选择成本最小的一个作为最终执行的执行计划。

如果我们想要查看某条sQL语句的查询成本，可以在执行完这条SQL语句之后，通过查看当前会话中的last_query_cost变量值来得到当前查询的成本。它通常也是我们评价一个查询的执行效率的一个常用指标。这个查询成本对应的是SQL语句所需要读取的页的数量。

我们依然使用第8章的student_info表为例:

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

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

运行结果(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 >= 900001 and id <= 9000100;

运行结果(10万条记录，运行时间为0.180s )

mysql> show status like 'last_query_cost';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| Last_query_cost | 21.134486 |
+-----------------+-----------+
1 row in set (0.00 sec)

你能看到页的数量是刚才的20倍，但是查询的效率并没有明显的变化，实际上这两个SQL查询的时间基本上一样，就是因为采用了顺序读取的方式将页面一次性加载到缓冲池中，然后再进行查找。虽然页数量(last_query_cost）增加了不少，但是通过缓冲池的机制，并没有增加多少查询时间。

$\textcolor{red}{使用场景:它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。}$

SQL查询是一个动态的过程，从页加载的角度来看，我们可以得到以下两点结论:

1.位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。

2.批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。

所以说，遇到I/O并不用担心，方法找对了，效率还是很高的。我们首先要考虑数据存放的位置，如果是经常使用的数据就要尽量放到缓冲池中，其次我们可以充分利用磁盘的吞吐能力，一次性批量读取数据，这样单个页的读取效率也就得到了提升。

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

MySQL的慢查询日志，用来记录在MySQL中响应时间**超过阀值的语句**，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上(不含10秒)）的语句，认为是超出了我们的最大忍耐时间值。

它的主要作用是，帮助我们发现那些执行时间特别长的SQL查询，并且有针对性地进行优化，从而提高系统的整体效率。当我们的数据库服务器发生阻塞、运行变慢的时候，检查一下慢查询日志，找到那些慢查询，对解决问题很有帮助。比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的SQL，结合explain进行全面分析。

默认情况下，MySQL数据库 $\textcolor{orange}{没有开启慢查询日志}$ ，需要我们手动来设置这个参数。**如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。**慢查询日志支持将日志记录写入文件。

4.1 开启慢查询日志功能

1.开启slow_query_log

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

SHOW VARIABLES LIKE '%slow_query_log';

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

mysql> set global slow_query_log='ON';

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

mysql> show variables like '%slow_query_log%';

你能看到这时慢查询分析已经开启，同时文件保存在/var/lib/mysql/hadoop103-slow.log文件中。

2.修改long_query_time阈值

接下来我们来看下慢查询的时间阈值设置，使用如下命令：

mysql> show variables like '%long_query_time%';

这里如果我们想把时间缩短，比如设置为 1 秒，可以这样设置：

# 测试发现：设置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';

$\textcolor{red}{补充:配置文件中一并设置参数}$
如下的方式相较于前面的命令行方式，可以看作是永久设置的方式。

修改my.cnf文件，[mysqld]下增加或修改参数long_query_time、slow_query_log 和slow_query_log_file后，然后重启MySQL服

务器。

[mysqld]
slow_query_log=ON  #开启慢查询日志的开关
slow_query_log_file=/var/lib/mysql/hadoop102-slow.log  #慢查询日志的目录和文件名信息
long_query_time=3 #设置慢查询的阈值为3秒，超出此设定值的SQL即被记录到慢查询日志
log_output=FILE

如果不指定存储路径，慢查询日志将默认存储到MySQL数据库的数据文件夹下。

如果不指定文件名，默认文件名为hostname-slow.log。

4.2 查看慢查询数目

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

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4.3 案例演示

步骤1. 建表

CREATE TABLE `student` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`stuno` INT NOT NULL ,
    `name` VARCHAR(20) DEFAULT NULL,
    `age` INT(3) DEFAULT NULL,
    `classId` INT(11) DEFAULT NULL,
    PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

步骤2：设置参数log_bin_trust_function_creators

创建函数，假如报错：

This function has none of DETERMINISTIC......

命令开启：允许创建函数设置：

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

步骤3：创建函数

随机产生字符串：（同上一章）

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 ;

产生随机数值：（同上一章）

#创建存储过程：
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 ;

步骤4：创建存储过程

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：调用存储过程

#调用刚刚写好的函数, 4000000条记录,从100001号开始
CALL insert_stu1(100001,4000000);

4.4 测试及分析

1. 测试

mysql> SELECT * FROM student WHERE stuno = 3455655;
+---------+---------+--------+------+---------+
| id      | stuno   | name   | age  | classId |
+---------+---------+--------+------+---------+
| 3355654 | 3455655 | NyebSj |   43 |     297 |
+---------+---------+--------+------+---------+
1 row in set (1.59 sec)


mysql> SELECT * FROM student WHERE name = 'oQmLUr';
+---------+---------+--------+------+---------+
| id      | stuno   | name   | age  | classId |
+---------+---------+--------+------+---------+
|  196567 |  296568 | oQmLUr |   98 |     876 |
|  274156 |  374157 | oQmLUr |  100 |     971 |
|  419455 |  519456 | Oqmlur |   55 |     488 |
|  814530 |  914531 | OQMlUR |   55 |     982 |
| 2288589 | 2388590 | OQMlUR |   57 |      80 |
| 2332144 | 2432145 | oqMLuR |   11 |     572 |
| 2782313 | 2882314 | Oqmlur |   56 |     513 |
| 3550744 | 3650745 | oQmLUr |   96 |     746 |
| 3711701 | 3811702 | oQmLUr |   11 |      68 |
| 3760179 | 3860180 | oQmLUr |  100 |     963 |
| 3975824 | 4075825 | oqMLuR |   11 |     548 |
+---------+---------+--------+------+---------+
11 rows in set (1.27 sec)

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

2. 分析

show status like 'slow_queries';

mysql> show status like 'slow_queries';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries  | 5     |
+---------------+-------+
1 row in set (0.01 sec)

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

mysql> show variables like ‘min%’;
±------------------------------------±---------------+
| Variable_name | Value |
±------------------------------------±---------------+
| min_examined_row_limit | 0 |
±------------------------------------±---------------+
1 row in set (0.00 sec)

这个值默认是0。与long_query_time=10合在一起，表示只要查询的执行时间超过10秒钟,哪怕一个记录都没有扫描过，都要被记录到慢查询日志中。你也可以根据需要，通过修改"my.ini"文件，来修改查询时长，或者通过SET指令，用SQL语句修改"min_examided_row_limit"的值。

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

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

mysqldumpslow --help   # 在命令行而不是mysql窗口

mysqldumpslow 命令的具体参数如下：

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

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

[root@hadoop103 mysql]# mysqldumpslow -s t -t 5 -a /var/lib/mysql/hadoop103-slow.log 

Reading mysql slow query log from /var/lib/mysql/hadoop103-slow.log
Count: 1  Time=4.55s (4s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@[192.168.202.1]
  CALL insert_s2(10001,10000)

Count: 1  Time=3.82s (3s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@[192.168.202.1]
  CALL insert_s1(10001,10000)

Count: 1  Time=1.58s (1s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
  SELECT * FROM student WHERE stuno = 3455655

Count: 1  Time=1.44s (1s)  Lock=0.00s (0s)  Rows=3.0 (3), root[root]@localhost
  select * from student where name = 'VcxgoZ'

Count: 1  Time=1.27s (1s)  Lock=0.00s (0s)  Rows=11.0 (11), root[root]@localhost
  SELECT * FROM student WHERE name = 'oQmLUr'

工作常用参考：

#得到返回结果集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop103-slow.log

#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/hadoop103-slow.log

#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/hadoop103-slow.log

#另外建议在使用这些命令时结合|和more使用 ，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/hadoop103-slow.log | more

4.6 关闭慢查询日志功能

MySQL服务器停止慢查询日志功能有两种方法：

方式1：永久性方式

[mysqld]
slow_query_log=OFF

或者，把slow_query_log一项注释掉删除

[mysqld]
#slow_query_log =OFF

重启MySQL服务，执行如下语句查询慢日志功能。

SHOW VARIABLES LIKE '%slow%'; #查询慢查询日志所在目录
SHOW VARIABLES LIKE '%long_query_time%'; #查询超时时长

方式2：临时性方式

使用SET语句来设置。

（1）停止MySQL慢查询日志功能，具体SQL语句如下。

SET GLOBAL slow_query_log=off;

（2）重启MySQL服务，使用SHOW语句查询慢查询日志功能信息，具体SQL语句如下

SHOW VARIABLES LIKE '%slow%';

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

4.7 删除慢查询日志

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

SHOW VARIABLES LIKE 'slow_query_log% ';

从执行结果可以看出，慢查询日志的目录默认为MySQL的数据目录，在该目录下手动删除慢查询日志文件即可。使用命令mysqladmin flush-logs 来重新生成查询日志文件，具体命令如下，执行完毕会在数据目录下重新生成慢查询日志文件。

mysqladmin -uroot -p flush-logs slow

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

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

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

mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | ON    |
+---------------+-------+
1 row in set (0.00 sec)


mysql> show profiles;
+----------+------------+--------------------------------------------------+
| Query_ID | Duration   | Query                                            |
+----------+------------+--------------------------------------------------+
|       18 | 0.00115275 | show variables like '%slow_query_log%'           |
|       19 | 0.00005100 | show variables like '%long_query_time%'          |
|       20 | 0.00137050 | show variables like '%long_query_time%'          |
|       21 | 0.00117325 | show variables like '%long_query_time%'          |
|       22 | 0.00119925 | show variables like 'long_query_time%'           |
|       23 | 0.00252550 | show variables like 'long_query_time'            |
|       24 | 0.00218475 | SHOW GLOBAL STATUS LIKE '%Slow_queries%'         |
|       25 | 0.00041325 | SELECT * FROM student_info WHERE stuno = 3455655 |
|       26 | 1.58461100 | SELECT * FROM student WHERE stuno = 3455655      |
|       27 | 1.27094075 | SELECT * FROM student WHERE name = 'oQmLUr'      |
|       28 | 0.00149875 | show status like 'slow_queries'                  |
|       29 | 0.00195000 | show variables like 'min%'                       |
|       30 | 0.00147475 | SHOW VARIABLES LIKE 'slow_query_log% '           |
|       31 | 0.00130400 | SHOW VARIABLES LIKE 'slow_query_log%'            |
|       32 | 0.00141200 | show variables like 'profiling'                  |
+----------+------------+--------------------------------------------------

如果我们想要查看最近一次查询的开销，可以使用:

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000070 |
| Executing hook on transaction  | 0.000006 |
| starting                       | 0.000009 |
| checking permissions           | 0.000007 |
| Opening tables                 | 0.000040 |
| init                           | 0.000006 |
| System lock                    | 0.000010 |
| optimizing                     | 0.000012 |
| statistics                     | 0.000015 |
| preparing                      | 0.000015 |
| executing                      | 1.270525 |
| end                            | 0.000015 |
| query end                      | 0.000005 |
| waiting for handler commit     | 0.000060 |
| closing tables                 | 0.000012 |
| freeing items                  | 0.000060 |
| logging slow query             | 0.000041 |
| cleaning up                    | 0.000033 |
+--------------------------------+----------+
18 rows in set, 1 warning (0.00 sec)

# 查询某一条语句的开销
mysql> show profile for query 5;

通过上面的结果，我们可以弄清楚每一步骤的耗时，以及在不同部分，比如CPU、block.io 的执行时间，这样我们就可以判断出来SQL到底慢在哪里。

show profile的常用查询参数:

① ALL：显示所有的开销信息。

② BLOCK IO：显示块lO开销。

③ CONTEXT SWITCHES：上下文切换开销。

④ CPU：显示CPU开销信息。

⑤ IPC：显示发送和接收开销信息。

⑥ MEMORY：显示内存开销信扈。

⑦ PAGE FAULTS：显示页面错误开销信息。

⑧ SOURCE：显示和Source_function，Source_file，Source_line相关的开销信息。

⑨ SWAPS：显示交换次数开销信息。

举例子：

show profile cpu,block io for query 5;

日常开发需注意的结论:

① converting HEAP to MyISAM: 查询结果太大，内存不够，数据往磁盘上搬了。

② Creating tmp table: 创建临时表。先拷贝数据到临时表，用完后再删除临时表。

③ Copying to tmp lable on disk : 把内存中临时表复制到磁盘上，警惕!

④ locked。

如果在show profile诊断结果中出现了以上4条结果中的任何一条，则sql语句需要优化。注意：不过SHOW PROFILE命令将被弃用，我们可以从 information_schema中的profiling数据表进行查看。

6.分析查询语句：EXPLAIN

6.1 概述

$\textcolor{red}{定位了查询慢的SQL之后，我们就可以使用EXFLAIN或 DESCRBE工具做针对性的分析查询语句}$ 。DESCRIBE语句的使用方法与EXPLAIN语句是一样的，并且分析结果也是一样的。

MysQL中有专门负责优化SELECT语句的优化器模块，主要功能:通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间)。

这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。MySQL为我们提供了EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，大家看懂EXPLAIN语句的各个输出项，可以有针对性的提升我们查询语句的性能。

$\textcolor{red}{1.能做什么?}$

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

$\textcolor{red}{2.官网介绍}$

https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

、

$\textcolor{red}{3.版本情况}$

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中的信息。

6.2 基本语法

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

EXPLAIN SELECT select_options
或者
DESCRIBE SELECT select_options

如果我们想看看某个查询的执行计划的话，可以在具体的查询语句前边加一个 EXPLAIN ，就像这样：

mysql> EXPLAIN SELECT 1;

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

注意：执行EXPLAIN时并没有真正的执行该后面的语句，因此可以安全的查看执行计划。

EXPLAIN语句输出的各个列的作用如下：

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

6.3 数据准备

6.3.1 建表

创建表 s1

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;

创建表 s2

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;

6.3.2 设置参数 log_bin_trust_function_creators

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

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

6.3.3 创建函数

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 ;

6.3.4 创建存储过程

创建往s1表中插入数据的存储过程

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 ;

创建往s2表中插入数据的存储过程

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 ;

6.3.5 调用存储过程

s1表数据的添加：加入1万条记录

CALL insert_s1(10001,10000);

s2表数据的添加：加入1万条记录

CALL insert_s2(10001,10000);

6.4 EXPLAIN各列作用

为了让大家有比较好的体验，我们调整了下 EXPLAIN 输出列的顺序。

1.table

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

mysql> EXPLAIN SELECT * FROM s1;

这个查询语句只涉及对s1表的单表查询，所以EXPLAIN输出中只有一条记录，其中的table列的值是s1，表明这条记录是用来说明对s1表的单表访问方法的。

下边我们看一个连接查询的执行计划:

mysql> EXPLAIN SELECT * FROM s1 JOIN s2;

可以看到这个连接查询的执行计划中有两条记录，这两条记录的table列分别是s1和s2，这两条记录用来分别说明对s1表和s2表的访问方法是什么。

2.id

我们写的查询语句一般都以 SELECT 关键字开头，比较简单的查询语句里只有一个 SELECT 关键字，比如下边这个查询语句：

SELECT * FROM s1 WHERE key1 = 'a';

稍微复杂一点的连接查询中也只有一个 SELECT 关键字，比如：

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

但是下边两种情况下在一条查询语句中会出现多个SELECT 关键字，explain就会有多条记录。

查询中包含子查询的情况
比如下边这个查询语句中就包含2个SELECT关键字:
```
explain SELECT * FROM  s1 WHERE key1 IN (SELECT key3 FROM s2);
```

查询中包含UNION语句的情况

比如下边这个查询语句中也包含2个SELECT 关键字:
```
explain SELECT * FROM s1 UNION SELECT * FROM s2;
```

查询语句中每出现一个SELECT关键字，MySQL就会为它分配一个唯一的id值。这个id值就是EXPLAIN语句的第一个列，比如下边这个查询中只有一个SELECT关键字，所以EXPLAIN的结果中也就只有一条id列为1的记录。

mysql> explain select * from s1 where key1 = 'a';

对于连接查询来说，一个SELECT关键字后边的FROM子句中可以跟随多个表，所以在连接查询的执行计划中，每个表都会对应一条记录，但是这些记录的id值都是相同的，比如：

explain select * from s1 inner join s2;

mysql> explain select * from s1 inner join s2;

可以看到，上述连接查询中参与连接的s1和s2表分别对应一条记录，但是这两条记录对应的id值都是1。这里需要大家记住的是，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的，出现在前边的表表示驱动表，出现在后边的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看出，查询优化器准备让s1表作为驱动表，让s2表作为被驱动表来执行查询。

对于包含子查询的查询语句来说，就可能涉及多个SELECT关键字，所以在包含子查询的查询语句的执行计划中，每个SELECT 关键字都会对应一个唯一的id值，比如这样:

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';

从输出结果中我们可以看到，s1表在外层查询中，外层查询有一个独立的SELECT关键字，所以第一条记录的id值就是1，s2表在子查询中，子查询有一个独立的SELECT 关键字，所以第二条记录的id值就是2。

但是这里大家需要特别注意，查询优化器可能对涉及子查询的查询语句进行重写，从而转换为连接查询。所以如果我们想知道查询优化器对某个包含子查询的语句是否进行了重写，直接查看执行计划就好了，比如说:

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

可以看到，虽然我们的查询语句是一个子查询，但是执行计划中s1和s2表对应的记录的id值全部是1，这就表明了查询优化器将子查询转换为了连接查询。

对于包含UNION子句的查询语句来说，每个SELECT关键字对应一个id值也是没错的，不过还是有点儿特别的东西，比方说下边这个查询:

mysql> EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

这个语句的执行计划的第三条记录是什么?为何id值是NULL，而且table列也很奇怪？UNION !它会把多个查询的结果集合并起来并对结果集中的记录进行去重，怎么去重呢? MySQL使用的是内部的临时表。正如上边的查询计划中所示，UNION子句是为了把id为1的查询和id为2的查询的结果集合并起来并去重，所以在内部创建了一个名为<union1，2>的临时表（就是执行计划第三条记录的table列的名称)，id为NULL表明这个临时表是为了合并两个查询的结果集而创建的。

跟UNION对比起来，UNION ALL就不需要为最终的结果集进行去重，它只是单纯的把多个查询的结果集中的记录合并成一个并返回给用户，所以也就不需要使用临时表。所以在包含UNION ALL子句的查询的执行计划中，就没有那个id为NULL的记录，如下所示：

mysql>  EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

小结:

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

3.select_type

一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表(这些表用来做连接查询)，每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。

MySQL为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色，我们看一下select_type都能取哪些值，请看官方文档：

具体分析如下：

SIMPLE

查询语句中不包含UNION或者子查询的查询都算作是SIMPLE类型，比方说下边这个单表查询的select_type的值就是SIMPLE :

 EXPLAIN SELECT * FROM s1;

当然，连接查询也算是 SIMPLE 类型，比如：

EXPLAIN SELECT * FROM s1 INNER JOIN s2;

PRIMARY

对于包含UNION、UNION ALL或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个查询的select_type值就是PRIMARY，比方说:

 EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

从结果中可以看到，最左边的小查询SELECT * FROM s1对应的是执行计划中的第一条记录，它的select_type值就是PRIMARY。

UNION

对于包含UNION或者UNION ALL的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询以外，其余的小查询的select_type值就是UNION，可以对比上一个例子的效果。
UNION RESULT

MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的查询的select_type就是UNIONRESULT，例子上边有。
SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join(多表连接)的形式，并且该子查询是不相关子查询，并且查询优化器决定采用将该子查询物化的方案来执行该子查询时，该子查询中的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY，比如下边这个查询:

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

DEPENDENT SUBQUERY

如果包含子查询的查询语句不能够转为对应的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';

DEPENDENT UNION

在包含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');

DERIVED

对于采用物化的方式执行的包含派生表的查询，该派生表对应的子查询的select_type就是DERIVED，比方说下边这个查询：

EXPLAIN SELECT * FROM (SELECT key1, COUNT(*) AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1;

从执行计划中可以看出，id为2的记录就代表子查询的执行方式，它的select_type是DERIVED，说明该子查询是以物化的方式执行的。id为1的记录代表外层查询，大家注意看它的table列显示的是<derived2>，表示该查询是针对将派生表物化之后的表进行查询的。

小贴士:如果派生表可以通过和外层查询合并的方式执行的话，执行计划又是另一番景象，大家可以试试。

MATERIALIZED

当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，该子查询对应的select_type属性就是MATERIALIZED，比如下边这个查询：

 EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2); #子查询被转为了物化表

物化是通过将子查询结果生成为一个临时表（通常在内存中）来加速查询执行。MySQL第一次需要子查询结果时，会将结果物化为一个临时表。任何后续需要该结果的时候，MySQL都会再次引用该临时表。优化器会使用散列索引对该表进行索引，从而使查找快速且低成本。

4.partitions

代表分区表中的命中情况，非分区表，该项为NULL。一般情况下我们的查询语句的执行计划的partitions列的值都是NULL。
https://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html
如果想详细了解，可以如下方式测试。创建分区表:

--创建分区表，
--按照id分区: id<100 p8分区  ， 其他p1分区
CREATE TABLE user_partitions (
    id INT auto_increment,
	NAME VARCHAR( 12),PRIMARY KEY(id) )
	PARTITION BY RANGE(id)(
	PARTITION p VALUEs less tlan(10日) ,
    PARTITION p1 VALUES less than MAXVALUE
);

查询id大于200（200>100，p1分区）的记录，查看执行计划，partitions是p1，符合我们的分区规则

DESC SELECT * FROM user_partitions WHERE id>200;

5.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。

System

当**表中只有一条记录并且该表使用的存储引擎的统计数据**是精确的，比如MylSAM、Memory，那么对该表的访问方法就是system。比方说我们新建一个MyISAM表，并为其插入一条记录:

CREATE TABLE t(
    i int
) Engine=MyISAM;

INSERT INTO t VALUES(1);

然后我们看一下查询这个表的执行计划：

mysql> EXPLAIN SELECT * FROM t;

可以看到type列的值就是system了。

测试:可以把表改成使用InnoDB存储引擎，试试看执行计划的type列是什么。ALL

const

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

mysql> EXPLAIN SELECT * FROM s1 WHERE id = 10005;

eq_ref

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

EXPLAIN SELECT * FROM s1 inner join s2 on s1.id = s2.id;

从执行计划的结果中可以看出，MySQL打算将s1作为驱动表，s2作为被驱动表，重点关注s2的访问方法是 eq_ref，表明在访问s1表的时候可以通过主键的等值匹配来进行访问。

ref

当**通过普通的二级索引列与常量进行等值匹配时来查询某个表**，那么对该表的访问方法就可能是ref。

 EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

ref_or_null

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

EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key1 IS NULL;

index_merge

一般情况下对于某个表的查询只能使用到一个索引，但单表访问方法时在某些场景下可以使用
Intersection(交集)、Union(并集)、Sort-Union这三种索引合并的方式来执行查询。我们看一下执行计划中是怎么体现MySQL使用索引合并的方式来对某个表执行查询的:

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

从执行计划的 type 列的值是 index_merge 就可以看出，MySQL 打算使用索引合并的方式来执行对 s1 表的查询。

unique_subquery

类似于两表连接中被驱动表的eq_ref访问方法， unique_subquery是针对在一些包含IN子查询的查询语句中，如果查询优化器决定将IN子查询转换为EXISTS子查询，而且子查询可以使用到主键进行等值匹配的话，那么该子查询执行计划的type列的值就是unique_subquery，比如下边的这个查询语句:

mysql> EXPLAIN SELECT * FROM s1 WHERE key2 IN (SELECT id FROM s2 where s1.key1 =
s2.key1) OR key3 = 'a';  # 子查询查id

可以看到执行计划的第二条记录的type值就是unique_subquery，说明在执行子查询时会使用到id列的索引。

index_subquery

mysql> EXPLAIN SELECT * FROM s1 WHERE common_field IN (SELECT key3 FROM s2 where
s1.key1 = s2.key1) OR key3 = 'a';   # 子查询查key3

index_subquery与unique_subquery类似，只不过访问子查询中的表时使用的是普通的索引。

range

如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法。

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

或者

EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';

index

当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是index，比如这样:

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

最熟悉的全表扫描

 EXPLAIN SELECT * FROM s1;

一般来说，这些访问方法中除了All这个访问方法外，其余的访问方法都能用到索引，除了index_merge访问方法外，其余的访问方法都最多只能用到一个索引。

小结:
结果值从最好到最坏依次是:
$\textcolor{blue}{system >const > eq\_ref > ref }$ >fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > $\textcolor{blue}{range > index > ALL}$

其中比较重要的几个提取出来（见上图中的蓝色)。SQL性能优化的目标:至少要达到range级别，要求是ref级别，最好是const级别。(阿里巴巴开发手册要求)

6.possible_keys和key

在EXPLAIN语句输出的执行计划中,possible_keys列表示在某个查询语句中，对某个表执行单表查询时可能用到的索引有哪些。一般查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。key列表示实际用到的索引有哪些，如果为NULL，则没有使用索引。比方说下边这个查询:

mysql> 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';

练习：

key_len的长度计算公式：

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

ref：当使用索引列等值查询时，与索引列进行等值匹配的对象信息。比如只是一个常数或者是某个列。

mysql> 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';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2UrJDqrL-1681804489975)(C:\Users\YBH\AppData\Roaming\Typora\typora-user-images\image-20230418151441976.png)]

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 ☆

顾名思义，Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。MySQL提供的额外信息有好几十个，我们就不一个一个介绍了，所以我们只挑比较重要的额外信息介绍给大家。

NO tables used

当查询语句没有FROM语句时将会提示额外信息，比如：
```
EXPLAIN SELECT 1;
```

Impossible WHERE

查询语句的WHERE子句永远为FALSE时将会提示该额外信息，比方说:

mysql> EXPLAIN SELECT * FROM s1 WHERE 1 != 1;

Using where

不用读取表中所有信息，仅通过索引就可以获取所需数据，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤。

当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。比如下边这个查询：

mysql> EXPLAIN SELECT * FROM s1 WHERE common_field = 'a';

当使用索引访问来执行对某个表的查询，并且该语句的WIHERE子句中有除了该索引包含的列之外的其他搜索条件时，在Extra列中也会提示上述额外信息。比如下边这个查询虽然使用idx_key1索引执行查询，但是搜索条件中除了包含key1的搜索条件key1 = ‘a’，还包含common_field的搜索条件，所以Extra列会显示Using where的提示:

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

Using index

当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用索引覆盖的情况下，在Extra列将会提示该额外信息。比方说下边这个查询中只需要用到idx_key1而不需要回表操作:

mysql> EXPLAIN SELECT key1 FROM s1 WHERE key1 = 'a';

Using index condition

有些搜索条件中虽然出现了索引列，但却不能使用到索引，比如下边这个查询:

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

其中的key1 > ‘z’ 可以使用到索引，但是key1 LIKE ‘%a’ 却无法使用到索引，在以前版本的MysQL中,是按照下边步骤来执行这个查询的:

先根据key1 > 'z’这个条件，从二级索引 idx_key1中获取到对应的二级索引记录。
根据上一步骤得到的二级索引记录中的主键值进行回表，找到完整的用户记录再检测该记录是否符合 key1 LIKE '%a’这个条件，将符合条件的记录加入到最后的结果集。

虽然 key1 LIKE '%a’不能组成范围区间参与range访问方法的执行，但这个条件毕竟只涉及到了key1列，所以MySQL把上边的步骤改进了一下:

先根据key1 > ‘z’ 这个条件，定位到二级索引 idx_key1中对应的二级索引记录。
对于指定的二级索引记录，先不着急回表，而是先检测一下该记录是否满足key1 LIKE '%a' 这个条件，如果这个条件不满足，则该二级索引记录压根儿就没必要回表。
对于满足key1 LIKE '%a'这个条件的二级索引记录执行回表操作。

我们说回表操作其实是一个随机IO，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。MySQL把他们的这个改进称之为索引条件下推(英文名: Index Condition Pushdown )。

如果在查询语句的执行过程中将要使用索引条件下推这个特性，在Extra列中将会显示Using indexcondition ，比如这样:

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

join_buffer

在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join buffer的内存块来加快查询速度，也就是我们所讲的基于块的嵌套循环算法。之后的章节会详细学到。

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

可以在对s2表的执行计划的Extra列显示了两个提示:

Using join buffer (Block Nested Loop)：这是因为对表s2的访问不能有效利用索引，只好退而求其次，使用join buffer来减少对s2表的访问次数，从而提高性能。
Using where: 可以看到查询语句中有一个s1.common_field = s2.common_field条件，因为s1是驱动表，s2是被驱动表，所以在访问s2表时, s1.common_field的值已经确定下来了，所以实际上查询s2表的条件就是 s2.common_field =一个常数，所以提示了Using where额外信息。
Not exists

当我们使用左(外）连接时，如果WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件，而且那个列又是不允许存储NULL值的，那么在该表的执行计划的Extra列就会提示Not exists额外信息，比如这样：

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

上述查询中s1表是驱动表，s2表是被驱动表, s2.id列是不允许存储NULL.值的，而WHERE子句中又包含s2.id IS NULL的搜索条件，这意味着必定是驱动表的记录在被驱动表中找不到匹配ON子句条件的记录才会把该驱动表的记录加入到最终的结果集，所以对于某条驱动表中的记录来说，如果能在被驱动表中找到条符合ON子句条件的记录，那么该驱动表的记录就不会被加入到最终的结果集，也就是说我们没有必要到被驱动表中找到全部符合ON子句条件的记录，这样可以稍微节省一点性能。

小贴士:右(外）连接可以被转换为左(外）连接，所以就不提右(外）连接的情况了。

Using intersect(…) ，Using union(…) 和 Using sort_union(…)

如果执行计划的Extra列出现了Using intersect( …)提示，说明准备使用Intersect索引合并的方式执行查询，括号中的…表示需要进行索引合并的索引名称;如果出现了Using union( …)提示，说明准备使用Union索引合并的方式执行查询;出现了Using sort_union( …)提示，说明准备使用Sort-Union索引合并的方式执行查询。比如这个查询的执行计划:

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

Zero limit

当我们的LIMIT子句的参数为0时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息，比如这样:

mysql> EXPLAIN SELECT * FROM s1 LIMIT 0;

Using filesort

有一些情况下对结果集中的记录进行排序是可以使用到索引的，比如下边这个查询:

mysql> EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;

这个查询语句可以利用idx_key1索引直接取出key1列的10条记录，然后再进行回表操作就好了。但是很多情况下排序操作无法使用到索引，只能在内存中(记录较少的时候）或者磁盘中(记录较多的时候）进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序(英文名: filesort)。如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra列中显示Using filesort提示，比如这样

mysql> EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;

需要注意的是，如果查询中需要使用filesort的方式进行排序的记录非常多，那么这个过程是很耗费性能的，我们最好想办法将使用文件排序的执行方式改为使用索引进行排序。

Using temporary

在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含DISTINCT、GROUP BY、UNION等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行计划的Extra列将会显示Using temporary提示

EXPLAIN SELECT DISTINCT common_field 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;

从 Extra 的 Using index 的提示里我们可以看出，上述查询只需要扫描 idx_key1 索引就可以搞定了，不再需要临时表了。

其它

其它特殊情况这里省略。

12. 小结

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

7. EXPLAIN的进一步使用

7.1 EXPLAIN四种输出格式

这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式， JSON格式， TREE格式以及可

视化输出。用户可以根据需要选择适用于自己的格式。

1.传统格式

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

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格式是四种格式里面输出信息最详尽的格式，里面包含了执行的成本信息。

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

EXPLAIN FORMAT=JSON SELECT ....

EXPLAIN的Column与JSON的对应关系:(来源于MySQL 5.7文档)

这样我们就可以得到一个json格式的执行计划，里面包含该计划花费的成本，比如这样:

mysq1> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G;

*************************** 1. row ***************************
EXPLAIN: {
  "query_block": {
    "select_id": 1,			#整个查询语句只有1个SELECT关键字，该关键字对应的id号为1
    "cost_info": {
      "query_cost": "1360.07"	#整个查询的执行成本预计为3197.16
    } /* cost_info */,
    "nested_loop": [  			#几个表之间采用嵌套循环连接算法执行
      {
        "table": {
          "table_name": "s1",	#s1表是驱动丧
          "access_type": "ALL",		#订问万法为ALL，意味着使用全表扫描访问
          "possible_keys": [		#可能使用的索引
            "idx_key1"
          ] /* possible_keys */,
          "rows_examined_per_scan": 9895,		#查询一次s1表大致需要扫描9895条记录
          "rows_produced_per_join": 989,		#驱动表s1的扇出是989
          "filtered": "10.00",					#condition filtering代表的百分比
          "cost_info": {
            "read_cost": "914.80",				#稍后解释
            "eval_cost": "98.95",				#稍后解释
            "prefix_cost": "1013.75",			#单次查询s1表总共的成本
            "data_read_per_join": "1M"			#读取的数据量
          } /* cost_info */,
          "used_columns": [						#执行查询中涉及到的列
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ] /* used_columns */,
          #对s1表访问时针对单表查询的条件
          "attached_condition": "((`atguigudb1`.`s1`.`common_field` = 'a') and (`atguigudb1`.`s1`.`key1` is not null))"
        } /* table */
      },
      {
        "table": {
          "table_name": "s2",		#s2表是被驱动表
          "access_type": "eq_ref",	#访问方法为ref，意味着使用索引等值匹配的方式访问
          "possible_keys": [		#可能使用的索引
            "idx_key2"
          ] /* possible_keys */,
          "key": "idx_key2",		#实际使用的索引
          "used_key_parts": [
            "key2"					#使用到的索引列
          ] /* used_key_parts */,
          "key_length": "5",		#key _len
          "ref": [					#与key2列进行等值匹配的对象
            "atguigudb1.s1.key1"
          ] /* ref */,
          "rows_examined_per_scan": 1,
          "rows_produced_per_join": 989,
          "filtered": "100.00",
          "index_condition": "(cast(`atguigudb1`.`s1`.`key1` as double) = cast(`atguigudb1`.`s2`.`key2` as double))",
          "cost_info": {
            "read_cost": "247.38",				#稍后解释
            "eval_cost": "98.95",				#稍后解释
            "prefix_cost": "1360.08",			#单次查询s1、多次查询s2表总共的成本
            "data_read_per_join": "1M"			#读取的数据量
          } /* cost_info */,
          "used_columns": [				#执行查询中涉及到的列
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ] /* used_columns */
        } /* table */
      }
    ] /* nested_loop */
  } /* query_block */
}
1 row in set, 2 warnings (0.00 sec)

我们使用 # 后边跟随注释的形式为大家解释了 EXPLAIN FORMAT=JSON 语句的输出内容，但是大家可能有疑问 “cost_info” 里边的成本看着怪怪的，它们是怎么计算出来的？先看 s1 表的 “cost_info” 部分：

"cost_info": {
	"read_cost": "1840.84",
	"eval_cost": "193.76",
	"prefix_cost": "2034.60",
	"data_read_per_join": "1M"
}

read_cost 是由下边这两部分组成的：
- IO 成本
- 检测 rows × (1 - filter) 条记录的 CPU 成本

小贴士： rows和filter都是我们前边介绍执行计划的输出列，在JSON格式的执行计划中，rows
相当于rows_examined_per_scan，filtered名称不变。

eval_cost 是这样计算的：

检测 rows × filter 条记录的成本。
prefix_cost 就是单独查询 s1 表的成本，也就是：

read_cost + eval_cost
data_read_per_join 表示在此次查询中需要读取的数据量。

对于 s2 表的 “cost_info” 部分是这样的：

"cost_info": {
	"read_cost": "968.80",
	"eval_cost": "193.76",
	"prefix_cost": "3197.16",
	"data_read_per_join": "1M"
}

由于 s2 表是被驱动表，所以可能被读取多次，这里的 read_cost 和 eval_cost 是访问多次 s2 表后累

加起来的值，大家主要关注里边儿的 prefix_cost 的值代表的是整个连接查询预计的成本，也就是单

次查询 s1 表和多次查询 s2 表后的成本的和，也就是：

968.80 + 193.76 + 2034.60 = 3197.16

3.TREE格式

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

述如何查询。

mysql> EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE
s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: -> Nested loop inner join (cost=1360.08 rows=990)
-> Filter: ((s1.common_field = 'a') and (s1.key1 is not null)) (cost=1013.75
rows=990)
-> Table scan on s1 (cost=1013.75 rows=9895)
-> Single-row index lookup on s2 using idx_key2 (key2=s1.key1), with index
condition: (cast(s1.key1 as double) = cast(s2.key2 as double)) (cost=0.25 rows=1)
1 row in set, 1 warning (0.00 sec)

4.可视化输出

可视化输出，可以通过MysQL Workbench可视化查看MysQL的执行计划。通过点击Workbench的放大镜图标，即可生成可视化的查询计划。

上图按从左到右的连接顺序显示表。红色框表示全表扫描，而绿色框表示使用索引查找。对于每个表，显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表的成本。

7.2 SHOW WARNINGS的使用

在我们使用EXPLAIN语句查看了某个查询的执行计划后，紧接着还可以使用 SHOW WARNINGS语句查看与这个查询的执行计划有关的一些扩展信息，比如这样:

mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE
s2.common_field IS NOT NULL;

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1003
Message: /* select#1 */ select `atguigu`.`s1`.`key1` AS `key1`,`atguigu`.`s2`.`key1`
AS `key1` from `atguigu`.`s1` join `atguigu`.`s2` where ((`atguigu`.`s1`.`key1` =
`atguigu`.`s2`.`key1`) and (`atguigu`.`s2`.`common_field` is not null))
1 row in set (0.00 sec)

大家可以看到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最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;

开启后，可分析如下语句：

SELECT
INSERT
REPLACE
DELETE
EXPLAIN
SET
DECLARE
CASE
IF
RETURN
CALL

测试：执行如下SQL语句

select * from student where id < 10;

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

select * from information_schema.optimizer_trace\G

** ** ** ** ** ** ** ** ** ** ** ** ** * 1. row ** ** ** ** ** ** ** ** ** ** ** ** ** *
	//第1部分：查询语句
	QUERY: select * from student where id < 10
//第2部分：QUERY字段对应语句的跟踪信息
TRACE: {
	"steps": [{
			"join_preparation": { //预备工作
				"select#": 1,
				"steps": [{
					"expanded_query": "/* select#1 */ select `student`.`id` AS
					`id`,
					`student`.
					`stuno`
					AS `stuno`,
					`student`.
					`name`
					AS `name`,
					`student`.
					`age`
					AS `age`,
					`student`.
					`classId`
					AS `classId`
					from `student`
					where(`student`.
						`id` < 10)
					"
				}] /* steps */
			} /* join_preparation */
		},
		{
			"join_optimization": { //进行优化
				"select#": 1,
				"steps": [{
						"condition_processing": { //条件处理
							"condition": "WHERE",
							"original_condition": "(`student`.`id` < 10)",
							"steps": [{
									"transformation": "equality_propagation",
									"resulting_condition": "(`student`.`id` < 10)"
								},
								{
									"transformation": "constant_propagation",
									"resulting_condition": "(`student`.`id` < 10)"
								},
								{
									"transformation": "trivial_condition_removal",
									"resulting_condition": "(`student`.`id` < 10)"
								}
							] /* steps */
						} /* condition_processing */
					},
					{
						"substitute_generated_columns": { //替换生成的列
						} /* substitute_generated_columns */
					},
					{
						"table_dependencies": [ //表的依赖关系
							{
								"table": "`student`",
								"row_may_be_null": false,
								"map_bit": 0,
								"depends_on_map_bits": [] /* depends_on_map_bits */
							}
						] /* table_dependencies */
					},
					{
						"ref_optimizer_key_uses": [ //使用键
						] /* ref_optimizer_key_uses */
					},
					{
						"rows_estimation": [ //行判断
							{
								"table": "`student`",
								"range_analysis": {
									"table_scan": {
										"rows": 3973767,
										"cost": 408558
									} /* table_scan */ , //扫描表
									"potential_range_indexes": [ //潜在的范围索引
										{
											"index": "PRIMARY",
											"usable": true,
											"key_parts": [
												"id"
											] /* key_parts */
										}
									] /* potential_range_indexes */ ,
									"setup_range_conditions": [ //设置范围条件
									] /* setup_range_conditions */ ,
									"group_index_range": {
										"chosen": false,
										"cause": "not_group_by_or_distinct"
									} /* group_index_range */ ,
									"skip_scan_range": {
										"potential_skip_scan_indexes": [{
											"index": "PRIMARY",
											"usable": false,
											"cause": "query_references_nonkey_column"
										}] /* potential_skip_scan_indexes */
									} /* skip_scan_range */ ,
									"analyzing_range_alternatives": { //分析范围选项
										"range_scan_alternatives": [{
											"index": "PRIMARY",
											"ranges": [
												"id < 10"
											] /* ranges */ ,
											"index_dives_for_eq_ranges": true,
											"rowid_ordered": true,
											"using_mrr": false,
											"index_only": false,
											"rows": 9,
											"cost": 1.91986,
											"chosen": true
										}] /* range_scan_alternatives */ ,
										"analyzing_roworder_intersect": {
											"usable": false,
											"cause": "too_few_roworder_scans"
										} /* analyzing_roworder_intersect */
									} /* analyzing_range_alternatives */ ,
									"chosen_range_access_summary": { //选择范围访问摘要
										"range_access_plan": {
											"type": "range_scan",
											"index": "PRIMARY",
											"rows": 9,
											"ranges": [
												"id < 10"
											] /* ranges */
										} /* range_access_plan */ ,
										"rows_for_plan": 9,
										"cost_for_plan": 1.91986,
										"chosen": true
									} /* chosen_range_access_summary */
								} /* range_analysis */
							}
						] /* rows_estimation */
					},
					{
						"considered_execution_plans": [ //考虑执行计划
							{
								"plan_prefix": [] /* plan_prefix */ ,
								"table": "`student`",
								"best_access_path": { //最佳访问路径
									"considered_access_paths": [{
										"rows_to_scan": 9,
										"access_type": "range",
										"range_details": {
											"used_index": "PRIMARY"
										} /* range_details */ ,
										"resulting_rows": 9,
										"cost": 2.81986,
										"chosen": true
									}] /* considered_access_paths */
								} /* best_access_path */ ,
								"condition_filtering_pct": 100, //行过滤百分比
								"rows_for_plan": 9,
								"cost_for_plan": 2.81986,
								9. MySQL监控分析视图 - sys schema "chosen": true
							}
						] /* considered_execution_plans */
					},
					{
						"attaching_conditions_to_tables": { //将条件附加到表上
							"original_condition": "(`student`.`id` < 10)",
							"attached_conditions_computation": [] /* attached_conditions_computation */ ,
							"attached_conditions_summary": [ //附加条件概要
								{
									"table": "`student`",
									"attached": "(`student`.`id` < 10)"
								}
							] /* attached_conditions_summary */
						} /* attaching_conditions_to_tables */
					},
					{
						"finalizing_table_conditions": [{
							"table": "`student`",
							"original_table_condition": "(`student`.`id` < 10)",
							"final_table_condition ": "(`student`.`id` < 10)"
						}] /* finalizing_table_conditions */
					},
					{
						"refine_plan": [ //精简计划
							{
								"table": "`student`"
							}
						] /* refine_plan */
					}
				] /* steps */
			} /* join_optimization */
		},
		{
			"join_execution": { //执行
				"select#": 1,
				"steps": [] /* steps */
			} /* join_execution */
		}
	] /* steps */
}
//第3部分：跟踪信息过长时，被截断的跟踪信息的字节数。
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0 //丢失的超出最大容量的字节
//第4部分：执行跟踪语句的用户是否有查看对象的权限。当不具有权限时，该列信息为1且TRACE字段为空，一般在
调用带有SQL SECURITY DEFINER的视图或者是存储过程的情况下， 会出现此问题。
INSUFFICIENT_PRIVILEGES: 0 //缺失权限
1 row in set(0.00 sec)

9. MySQL监控分析视图-sys schema

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

9.1 Sys schema视图摘要

1. **主机相关：**以host_summary开头，主要汇总了IO延迟的信息。

**2. Innodb相关：**以innodb开头，汇总了innodb buffer信息和事务等待innodb锁的信息。

**3. I/o相关：**以io开头，汇总了等待I/O、I/O使用量情况。

4. **内存使用情况：**以memory开头，从主机、线程、事件等角度展示内存的使用情况

5. **连接与会话信息：**processlist和session相关视图，总结了会话相关信息。

6. **表相关：**以schema_table开头的视图，展示了表的统计信息。

7. **索引信息：**统计了索引的使用情况，包含冗余索引和未使用的索引情况。

8. **语句相关：**以statement开头，包含执行全表扫描、使用临时表、排序等的语句信息。

9. **用户相关：**以user开头的视图，统计了用户使用的文件I/O、执行语句统计信息。

10. **等待事件相关信息：**以wait开头，展示等待事件的延迟情况。

9.2 Sys schema视图使用场景

$\textcolor{red}{索引情况}$

#1. 查询冗余索引
select * from sys.schema_redundant_indexes;
#2. 查询未使用过的索引
select * from sys.schema_unused_indexes;
#3. 查询索引的使用情况
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted
from sys.schema_index_statistics where table_schema='dbname' ;

$\textcolor{red}{表相关}$

# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from
sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';

$\textcolor{red}{语句相关}$

#1. 监控SQL执行的频率
select db,exec_count,query from sys.statement_analysis
order by exec_count desc;
#2. 监控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 监控使用了临时表或者磁盘临时表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0
order by (tmp_tables+tmp_disk_tables) desc;

$\textcolor{red}{IO相关}$

#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;

$\textcolor{red}{Innodb相关}$

#1. 行锁阻塞情况
select * from sys.innodb_lock_waits;