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

1.查看系统性能参数

在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：删除操作的次数。

mysql> show status like 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 74    |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show status like 'connections';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Connections   | 8     |
+---------------+-------+
1 row in set (0.00 sec)
mysql>

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

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

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

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

mysql> SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id = 900001;
+------------+----------+--------+---------------------+
| student_id | class_id | NAME   | create_time         |
+------------+----------+--------+---------------------+
|      57487 |    10136 | vjHLJY | 2022-02-20 01:12:35 |
+------------+----------+--------+---------------------+
1 row in set (0.00 sec)
mysql>

然后再看下查询优化器的成本，实际上我们只需要检索一个页即可：

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

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

mysql> SELECT student_id,class_id, NAME, create_time FROM student_info WHERE id BETWEEN 900001 AND 900100;
......
mysql> show status like 'last_query_cost';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| Last_query_cost | 20.290502 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql>

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

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

1. 位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。
2. 批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多10ms)，而采用顺序读取的方式，批量对页进行读取，平均一页的读取效率就会提升很多，甚至要快于单个页面在内存中的随机读取。

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

3.定位执行慢的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';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | OFF   |
+----------------+-------+
1 row in set (0.08 sec)
mysql> set global slow_query_log = on;
Query OK, 0 rows affected (0.02 sec)
mysql> show variables like '%slow_query_log';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | ON    |
+----------------+-------+
1 row in set (0.01 sec)
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------+
| Variable_name       | Value                             |
+---------------------+-----------------------------------+
| slow_query_log      | ON                                |
| slow_query_log_file | /var/lib/mysql/localhost-slow.log |
+---------------------+-----------------------------------+
2 rows in set (0.01 sec)
mysql>

1. 修改long_query_time的阈值 ```shell mysql> show variables like ‘%long_query_time%’; +————————-+—————-+ | Variable_name | Value | +————————-+—————-+ | long_query_time | 10.000000 | +————————-+—————-+ 1 row in set (0.00 sec)

mysql> set global long_query_time = 1; Query OK, 0 rows affected (0.00 sec)

mysql>

**补充：配置文件中一并设置参数**<br />如下的方式相较于前面的命令行方式，可以看作是永久设置的方式。<br />修改my.cnf文件，[mysqld]下增加或修改参数long_query_time、 slow_query_log和slow_query_log_file后，然后重启MySQL服务器。
```properties
[mysqld]
#开启慢查询日志的开关
slow_query_log=ON 
#慢查询日志的目录和文件名信息
slow_query_log_file=/var/lib/mysql/localhost-slow.log
#设置慢查询的阈值为3秒，超出此设定值的SQL即被记录到慢查询日志
long_query_time=3
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只在当前窗口有效

1. 创建函数

同上一章

1. 创建存储过程

   DELIMITER //
   CREATE PROCEDURE insert_stu1(START INT, max_num INT) 
   BEGIN
   DECLARE i INT DEFAULT 0;
    SET autocommit = 0; #设置手动提交事务
   REPEAT #循环
    SET i = i + 1; #赋值
   INSERT INTO student (stuno, NAME, age, classId) 
   VALUES ((START + i), rand_string(6), rand_num(10, 100), rand_num(10,1000));
   UNTIL i = max_num
    END REPEAT;
    COMMIT; #提交事务
   END // 
   DELIMITER;

2. 调用存储过程

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

   4.4测试及分析

3. 测试 ```shell mysql> select * from student where name like ‘%PiwJfx’ or name like ‘tmeLrC’; +————-+————-+————+———+————-+ | id | stuno | name | age | classId | +————-+————-+————+———+————-+ | 115276 | 215277 | tmeLrC | 76 | 23 | | 211452 | 311453 | TmElrc | 28 | 860 | | 474305 | 574306 | PiwJfx | 100 | 581 | | 900001 | 1000002 | PiwJfx | 99 | 552 | | 1114014 | 1214015 | TmElrc | 26 | 762 | | 1149030 | 1249031 | tMELRc | 71 | 252 | | 1379271 | 1479272 | PiwJfx | 96 | 420 | | 1478011 | 1578012 | piWjfX | 54 | 598 | | 1557932 | 1657933 | PiwJfx | 100 | 588 | | 1717302 | 1817303 | tMELRc | 73 | 371 | | 1887629 | 1987630 | PIWJFX | 95 | 877 | | 2076512 | 2176513 | tMELRc | 75 | 431 | | 2360040 | 2460041 | piWjfX | 52 | 458 | | 2883316 | 2983317 | pIwjFx | 55 | 106 | | 3131143 | 3231144 | tmeLrC | 71 | 746 | | 3198060 | 3298061 | PiwJfx | 100 | 615 | | 3289108 | 3389109 | PiwJfx | 94 | 334 | | 3353136 | 3453137 | TMelRC | 26 | 286 | | 3398874 | 3498875 | pIwjFx | 50 | 889 | | 3623437 | 3723438 | TmElrc | 27 | 809 | | 3646214 | 3746215 | tMELRc | 75 | 435 | | 3690021 | 3790022 | tmeLrC | 73 | 845 | | 3937391 | 4037392 | PIWJFX | 94 | 825 | +————-+————-+————+———+————-+ 23 rows in set (1.19 sec)

从上面可以看出查询已经达到了秒量级别，说明目前查询效率还是比较低的，下面小节我们分析一下原因。
2. **分析**
```sql
mysql> show status like 'slow_queries%';

补充说明： 除了上述变量，控制慢查询日志的还有一个系统变量：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)
mysql>

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

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

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

[root@tang ~]# mysqldumpslow --help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]
Parse and summarize the MySQL slow query log. Options are
  --verbose    verbose
  --debug      debug
  --help       write this text to standard output
  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default
                al: average lock time
                ar: average rows sent
                at: average query time
                 c: count
                 l: lock time
                 r: rows sent
                 t: query time  
  -r           reverse the sort order (largest last instead of first)
  -t NUM       just show the top n queries
  -a           don't abstract all numbers to N and strings to 'S'
  -n NUM       abstract numbers with at least n digits within names
  -g PATTERN   grep: only consider stmts that include this string
  -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),
               default is '*', i.e. match all
  -i NAME      name of server instance (if using mysql.server startup script)
  -l           don't subtract lock time from total time
[root@tang ~]#

具体参数如下：

• -a：不将数字抽象成N，不将字符串抽象成S
• -s：表示按照何种方式排序：
  • c：访问次数
  • l：锁定时间
  • r：返回记录数
  • t：查询时间
  • al：平均锁定时间
  • ar：平均返回记录数
  • at：平均查询时间（默认方式）
  • ac：平均查询次数
• -t：返回前几条数据 ```shell [root@tang mysql]# mysqldumpslow -a -s t -t 5 /var/lib/mysql/localhost-slow.log

Reading mysql slow query log from /var/lib/mysql/localhost-slow.log Count: 1 Time=1094.06s (1094s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@[192.168.25.1] CALL insert_stu1(100001, 4000000)

Count: 1 Time=1.19s (1s) Lock=0.00s (0s) Rows=23.0 (23), root[root]@localhost select * from student where name like ‘%PiwJfx’ or name like ‘tmeLrC’

Died at /usr/bin/mysqldumpslow line 162, <> chunk 2. [root@tang mysql]#

<a name="ShLrT"></a>
## 4.6关闭慢查询日志
MySQL服务器停止慢查询日志有两种方式：<br />**方式一：永久性方式**<br />修改my.cnf或者my.ini文件，把[mysqld]组下的slow_query_log值设置为OFF，修改保存后，再重启MySQL服务，即可生效；
```properties
[mysqld]
slow_query_log=OFF

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

[mysqld]
#slow_query_log = OFF

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

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

可以看到，MySQL系统中的慢查询日志是关闭的。
方式二：临时性方式
使用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语句如下。

mysql> SHOW VARIABLES LIKE 'slow_query_log%';
+---------------------+-----------------------------------+
| Variable_name       | Value                             |
+---------------------+-----------------------------------+
| slow_query_log      | ON                                |
| slow_query_log_file | /var/lib/mysql/localhost-slow.log |
+---------------------+-----------------------------------+
2 rows in set (0.00 sec)
mysql>

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

[root@tang ~]# mysqladmin -uroot -p flush-logs slow

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

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

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

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

通过 profiling=’ON’ 来开启show profile

mysql> set profiling = 'ON';
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql>

然后执行相关语句：

mysql> show profiles;

可以看到当前会话一共有6个查询，如果我们想要查看最近一次查询的开销，可以用：

mysql> show profile;

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

mysql> show profile cpu, block io for query 6;

通过上面的结果，我们可以弄清楚每一步骤的耗时，以及在不同部分，比如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：显示交换次数开销信息。

日常开发需注意的结论：

1. converting HEAP to MyISAM：查询结果太大，内存不够，数据往磁盘上搬了。
2. Creating tmp table：创建临时表。先拷贝数据到临时表，用完后再删除临时表。
3. Copying to tmp table on disk：把内存中临时表复制到磁盘上，警惕!
4. locked。

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

6.分析查询语句：EXPLAIN

6.1概述

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

1. 能做什么？

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

1. 官网介绍

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

1. 版本情况

• MySQL5.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，如：

  EXPLAIN SELECT NOW();

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

注意：执行EXPLAIN时并没有真正的执行该后面的语句，因此可以安全的查看执行计划。
EXPLAIN语句输出的各个列的作用如下：

6.3数据准备

1. 建表 ```sql 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_fie1d 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;

```sql
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_fie1d 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;

1. 设置参数log_bin_trust_function_creators

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

set global log_bin_trust_function_creators=1;

1. 创建函数

   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 ;

2. 创建存储过程

创建往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 ;

1. 调用存储过程

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

CALL insert_s1(10001, 10000);

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

CALL insert_s2(10001, 10000);

6.4 EXPLAIN各列作用

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

1. table

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

EXPLAIN SELECT * FROM s1;

下面看一个连表查询的执行计划：

EXPLAIN SELECT * FROM s1 INNER JOIN s2;

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

2. id

在一个大的查询语句中每个SELECT关键字都对应着一个唯一的id

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

连接查询：

 EXPLAIN SELECT * FROM s1 INNER JOIN s2;

可以看到，此时的SQL语句有两个表，分别对应着两条记录，可是SELECT关键字只有一个，因此两条记录的id都为1。

子查询：

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

外层的SELECT查询对应着id=1的记录，里面的子查询对应着id=2的记录。

由上面两个例子可见一个SELECT关键字分别对应着不同的id。但并非所有的都是如此，比如下面的SQL：

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

如图，上面的SQL虽然有两个SELECT关键字，但是执行的得到的两个记录的id都等于1。原因是查询优化器可能对涉及子查询的查询语句进行重写，转变为多表连接查询的操作。

Union去重：

 EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

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

由于union查询出的数据需要进行去重处理，因此MySQL在查询出s1和s2表中的数据后，会将查出的数据整到一个临时表中进行去重。由于临时表并不对应SQL中的SELECT关键字，所以会得出一个id为空的记录。

小结：

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

  3. select_type

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

  查询语句中不包含UNION或者子查询的查询都算作是SIMPLE类型

  mysql> EXPLAIN SELECT * FROM s1; +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ | 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ 1 row in set, 1 warning (0.00 sec)

mysql>

连接查询也算是SIMPLE类型

mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2; +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———————————————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———————————————-+ | 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | | 1 | SIMPLE | s2 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | Using join buffer (hash join) | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———————————————-+ 2 rows in set, 1 warning (0.00 sec)

mysql>

对于包含UNION或者UNION ALL或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个

查询的select_type值就是PRIMARY

对于包含UNION或者UNION ALL的大查询来说，它是由几个小查询组成的，其中除了最左边的那个小查询

以外，其余的小查询的select_type值就是UNION

MySQL选择使用临时表来完成UNION查询的去重工作，针对该临时表的查询的select_type就是

UNION RESULT

mysql> EXPLAIN SELECT FROM s1 UNION SELECT FROM s2; +——+———————+——————+——————+———+———————-+———+————-+———+———+—————+————————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+———————+——————+——————+———+———————-+———+————-+———+———+—————+————————-+ | 1 | PRIMARY | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | | 2 | UNION | s2 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | | NULL | UNION RESULT | | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | Using temporary | +——+———————+——————+——————+———+———————-+———+————-+———+———+—————+————————-+ 3 rows in set, 1 warning (0.01 sec)

mysql> EXPLAIN SELECT FROM s1 UNION ALL SELECT FROM s2; +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ | 1 | PRIMARY | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | | 2 | UNION | s2 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | +——+——————-+———-+——————+———+———————-+———+————-+———+———+—————+———-+ 2 rows in set, 1 warning (0.00 sec)

mysql>

子查询：

如果包含子查询的查询语句不能够转为对应的semi-join的形式(多表连接查询join)，并且该子查询是不相关子查询。

该子查询的第一个SELECT关键字代表的那个查询的select_type就是SUBQUERY

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = ‘a’; +——+——————-+———-+——————+———-+———————-+—————+————-+———+———+—————+——————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————-+———-+——————+———-+———————-+—————+————-+———+———+—————+——————-+ | 1 | PRIMARY | s1 | NULL | ALL | idx_key3 | NULL | NULL | NULL | 9895 | 100.00 | Using where | | 2 | SUBQUERY | s2 | NULL | index | idx_key1 | idx_key1 | 303 | NULL | 9895 | 100.00 | Using index | +——+——————-+———-+——————+———-+———————-+—————+————-+———+———+—————+——————-+ 2 rows in set, 1 warning (0.00 sec)

mysql>

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是相关子查询，

则该子查询的第一个SELECT关键字代表的那个查询的select_type就是DEPENDENT SUBQUERY

注意的是，select_type为DEPENDENT SUBQUERY的查询可能会被执行多次。

mysql> EXPLAIN SELECT * FROM s1 -> WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = ‘a’; +——+——————————+———-+——————+————+—————————-+—————+————-+——————————+———+—————+——————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————————+———-+——————+————+—————————-+—————+————-+——————————+———+—————+——————-+ | 1 | PRIMARY | s1 | NULL | ALL | idx_key3 | NULL | NULL | NULL | 9895 | 100.00 | Using where | | 2 | DEPENDENT SUBQUERY | s2 | NULL | eq_ref | idx_key2,idx_key1 | idx_key2 | 5 | atguigudb1.s1.key2 | 1 | 10.00 | Using where | +——+——————————+———-+——————+————+—————————-+—————+————-+——————————+———+—————+——————-+ 2 rows in set, 2 warnings (0.00 sec)

mysql>

在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了

最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION。

注意：这里SQL看起来IN里面的SELECT查询并没有依赖外层，但实际执行时优化器会将该SQL转换成EXISTS查询

mysql> EXPLAIN SELECT * FROM s1 -> WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = ‘a’ UNION SELECT key1 FROM s1 WHERE key1 = ‘b’); +——+——————————+——————+——————+———+———————-+—————+————-+———-+———+—————+—————————————+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————————+——————+——————+———+———————-+—————+————-+———-+———+—————+—————————————+ | 1 | PRIMARY | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | Using where | | 2 | DEPENDENT SUBQUERY | s2 | NULL | ref | idx_key1 | idx_key1 | 303 | const | 1 | 100.00 | Using where; Using index | | 3 | DEPENDENT UNION | s1 | NULL | ref | idx_key1 | idx_key1 | 303 | const | 1 | 100.00 | Using where; Using index | | NULL | UNION RESULT | | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | Using temporary | +——+——————————+——————+——————+———+———————-+—————+————-+———-+———+—————+—————————————+ 4 rows in set, 1 warning (0.00 sec)

mysql>

对于包含派生表的查询，该派生表对应的子查询的select_type就是DERIVED

mysql> EXPLAIN SELECT -> FROM (SELECT key1, COUNT() AS c FROM s1 GROUP BY key1) AS derived_s1 WHERE c > 1; +——+——————-+——————+——————+———-+———————-+—————+————-+———+———+—————+——————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+——————-+——————+——————+———-+———————-+—————+————-+———+———+—————+——————-+ | 1 | PRIMARY | | NULL | ALL | NULL | NULL | NULL | NULL | 9895 | 100.00 | NULL | | 2 | DERIVED | s1 | NULL | index | idx_key1 | idx_key1 | 303 | NULL | 9895 | 100.00 | Using index | +——+——————-+——————+——————+———-+———————-+—————+————-+———+———+—————+——————-+ 2 rows in set, 1 warning (0.00 sec)

mysql>

当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询时，

该子查询对应的select_type属性就是MATERIALIZED

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2); #子查询被转为了物化表 +——+———————+——————-+——————+————+——————————-+——————————-+————-+——————————+———+—————+——————-+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +——+———————+——————-+——————+————+——————————-+——————————-+————-+——————————+———+—————+——————-+ | 1 | SIMPLE | s1 | NULL | ALL | idx_key1 | NULL | NULL | NULL | 9895 | 100.00 | Using where | | 1 | SIMPLE | | NULL | eq_ref | | | 303 | atguigudb1.s1.key1 | 1 | 100.00 | NULL | | 2 | MATERIALIZED | s2 | NULL | index | idx_key1 | idx_key1 | 303 | NULL | 9895 | 100.00 | Using index | +——+———————+——————-+——————+————+——————————-+——————————-+————-+——————————+———+—————+——————-+ 3 rows in set, 1 warning (0.00 sec)

mysql>

<a name="XskmN"></a>
### 4. partitions（可略）
- 代表分区表中的命中情况，非分区表，该项为NULL。一般情况下我们的查询语句的执行计划的partitions列的值都是NULL。
- [https://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html](https://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html·)
- 如果想详细了解，可以如下方式测试。创建分区表：
```sql
--创建分区表，
--按照id分区，id<100 p0分区，其他p1分区
CREATE TABLE user_partitions (
  `id` INT auto_increment,
  `name` VARCHAR(12),
  PRIMARY KEY(id))
  PARTITION BY RANGE(id)(
    PARTITION p0 VALUES less than(100),
    PARTITION p1 VALUES less than MAXVALUE
);

mysql> DESC SELECT * FROM user_partitions WHERE id > 200;
+----+-------------+-----------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table           | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-----------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | user_partitions | p1         | range | PRIMARY       | PRIMARY | 4       | NULL |    1 |   100.00 | Using where |
+----+-------------+-----------------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)
mysql>

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

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。

# type：针对单表的访问方法
#############################
# 当表中`只有一条记录`并且该表使用的存储引擎的统计数据是精确的，比如MyISAM、Memory，
# 那么对该表的访问方法就是`system`。
mysql>  CREATE TABLE t(i INT) ENGINE=MYISAM;
Query OK, 0 rows affected (0.02 sec)
mysql>  INSERT INTO t VALUES(1);
Query OK, 1 row affected (0.02 sec)
mysql> EXPLAIN SELECT * FROM t;
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t     | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+--------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.01 sec)
# 此时表中只有一条数据，当我们查看执行计划时，可以看到此时的type为system
# 而如果我们再往表里再插入一条数据时，再去查看执行计划
mysql> INSERT INTO t VALUES(1);
Query OK, 1 row affected (0.00 sec)
mysql> EXPLAIN SELECT * FROM t;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | t     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
mysql>
# 可以看出此时type为ALL
# 下面换成InnoDB试试
mysql> CREATE TABLE tt(i INT) ENGINE=INNODB;
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO tt VALUES(1);
Query OK, 1 row affected (0.01 sec)
mysql> EXPLAIN SELECT * FROM tt;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | tt    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.01 sec)
# 可以看出当存储引擎为InnoDB时，即使数据表内只有一条数据，type依旧为ALL。
############################
1、
#当我们根据 主键 或者 唯一二级索引 列与常数进行等值匹配时，对单表的访问方法就是`const`
mysql> EXPLAIN SELECT * FROM s1 WHERE id = 10005;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.01 sec)
mysql> EXPLAIN SELECT * FROM s1 WHERE key2 = 10066;
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | const | idx_key2      | idx_key2 | 5       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+----------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
# 因为id和key2都有唯一索引，在遍历到数据页时可以直接拿出该条匹配记录，
# 不需要再对该记录的后续数据节点或数据页进行遍历，因为该列数据都是唯一的，不可能有与其重复的记录。当type为const性能也是很不错的
2、
#在连接查询时，如果被驱动表是通过主键或者唯一二级索引列等值匹配的方式进行访问的
#（如果该主键或者唯一二级索引是联合索引的话，所有的索引列都必须进行等值比较），则
#对该被驱动表的访问方法就是`eq_ref`
mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref              | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ALL    | PRIMARY       | NULL    | NULL    | NULL             | 9895 |   100.00 | NULL  |
|  1 | SIMPLE      | s2    | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | atguigudb1.s1.id |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
2 rows in set, 1 warning (0.00 sec)
# s1为驱动表，s2为被驱动表。
# 查询时先将s1表的所有数据查询出来，再遍历每一条根据条件去查询s2。因此s1表的type为ALL。
# 由于被驱动表是根据id去查询的，在查询时最多只有一条记录会匹配上，因此type为eq_ref，此时的查询效率也是不错的
##########################
1、
#当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是`ref`
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)
#################################
1、
#当对普通二级索引进行等值匹配查询，该索引列的值也可以是`NULL`值时，那么对该表的访问方法就可能是`ref_or_null`
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key1 IS NULL;
+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+
| id | select_type | table | partitions | type        | possible_keys | key      | key_len | ref   | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | ref_or_null | idx_key1      | idx_key1 | 303     | const |    2 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------------+---------------+----------+---------+-------+------+----------+-----------------------+
1 row in set, 1 warning (0.02 sec)
################################
1、
# 单表访问方法时在某些场景下可以使用`Intersection`、`Union`、`Sort-Union`这三种索引合并的方式来执行查询
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
| id | select_type | table | partitions | type        | possible_keys     | key               | key_len | ref  | rows | filtered | Extra                                       |
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
|  1 | SIMPLE      | s1    | NULL       | index_merge | idx_key1,idx_key3 | idx_key1,idx_key3 | 303,303 | NULL |    2 |   100.00 | Using union(idx_key1,idx_key3); Using where |
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
1 row in set, 1 warning (0.02 sec)
# 此时，会同时用到两个个索引idx_key1,idx_key3，会将两个索引查出的结果取并集Using union(idx_key1,idx_key3);
# 参考https://www.cnblogs.com/digdeep/archive/2015/11/18/4975977.html
#################################
1、
#`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 | select_type        | table | partitions | type            | possible_keys    | key     | key_len | ref  | rows | filtered | Extra       |
+----+--------------------+-------+------------+-----------------+------------------+---------+---------+------+------+----------+-------------+
|  1 | PRIMARY            | s1    | NULL       | ALL             | idx_key3         | NULL    | NULL    | NULL | 9895 |   100.00 | Using where |
|  2 | DEPENDENT SUBQUERY | s2    | NULL       | unique_subquery | PRIMARY,idx_key1 | PRIMARY | 4       | func |    1 |    10.00 | Using where |
+----+--------------------+-------+------------+-----------------+------------------+---------+---------+------+------+----------+-------------+
2 rows in set, 2 warnings (0.01 sec)
# 转换后的SQL：
EXPLAIN SELECT * FROM s1 WHERE EXISTS (
    SELECT id FROM s2 WHERE s1.key2 = s2.id AND s1.key1 = s2.key1
) OR key3 = 'a'; 
# 此时，子查询中使用到s2表主键作为条件进行查询，因此子查询的type为unique_subquery，
# 奇怪的是子查询条件中也用到了key1作为条件进行查询，但为何实际使用的索引并没有用到idx_key1？
# 因为idx_key1为二级索引，在查询到符合的数据（s1.key1 = s2.key1）还要拿id进行回表，查询主键索引，
# 此时拿到的id有不一定符合条件（s1.key2 = s2.id），不仅在使用idx_key1索引加载了数据页，还在使用主键索引加载了无用的数据页
# 造成I/O操作的增加，还不如直接使用主键索引，将符合记录的数据页加载到内存，在内存中进行s1.key1 = s2.key1的条件筛选
##########################################
1、
#如果使用索引获取某些`范围区间`的记录，那么就可能使用到`range`访问方法
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN ('a', 'b', 'c');
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |    3 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.01 sec)
#同上
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'a' AND key1 < 'b';
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |  395 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)
#######################################
1、
#当我们可以使用索引覆盖，但需要扫描全部的索引记录时，该表的访问方法就是`index`
mysql> EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
| id | select_type | table | partitions | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra                    |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
|  1 | SIMPLE      | s1    | NULL       | index | idx_key_part  | idx_key_part | 909     | NULL | 9895 |    10.00 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
1 row in set, 1 warning (0.01 sec)
########################
1、
#最熟悉的全表扫描
mysql> EXPLAIN SELECT * FROM s1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

小结：
结果值从最好到最坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
其中比较重要的几个提取出来（见上图中的蓝色）。SQL性能优化的目标：至少要达到range级别，要求是ref级别，最好是consts级别。（阿里巴巴开发手册要求）

6. possible_keys和key

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

7. key_len (重要)

实际使用到的索引长度（即：字节数），帮你检查是否充分的利用上了索引，值越大越好。主要针对于联合索引，有一定的参考意义。以s1表的联合索引idx_key_part为例：

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a';
+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key          | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key_part  | idx_key_part | 303     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b';
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key          | key_len | ref         | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key_part  | idx_key_part | 606     | const,const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c';
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key          | key_len | ref               | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key_part  | idx_key_part | 909     | const,const,const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+--------------+---------+-------------------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

当以key_part1为条件去查询索引idx_key_part时，此时用到的索引长度为303。因为key_part1的字段类型为varchar(100)，而所用的编码为utf8，所以该字段所占的字节数为3100=300。由于该字段为变长字段，根据之前章节行格式的特点，需要两个字节去存储其真实所占的字节数，因此长度为3100+2=302。最后由于该字段允许NULL，还需要花费一个字节去表示该字段的值是否为NULL。最终长度为3*100+2+1=303。

练习：

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)

对于联合索引，执行计划中key_len的值越大越好，越大表明索引的利用率越高，查询效率越快。

idx_key_part索引有3个字段key_part1、key_part2、key_part3构成，假设该索引数据页中的一条用户记录所占字节大小为909。当只以key_part1作为条件进行查询时，key_len为303，此时的查询条件比较模糊，只能匹配到用户记录的部分数据，可能该数据页中用户记录的key_part1部分都是相同的，甚至连着几个数据页这部分都是一样的，因此需要把几个数据页都加载到内存中。而当以key_part1、key_part2、key_part3作为条件进行查询时，能够完全匹配上某一条用户记录，而其他记录都不能符合该查询条件，此时只要将这一个数据页加载到内存即可，大大减少了磁盘I/O。因此，key_len越大，表示查询的范围越小，精度越高，能大大减少检索以及磁盘I/O操作。

8. ref

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

1、当使用常数去进行查询时，ref的值为const
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> 

2、当使用某个列进行查询时，ref的值为该列的名称
mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref              | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
|  1 | SIMPLE      | s1    | NULL       | ALL    | PRIMARY       | NULL    | NULL    | NULL             | 9895 |   100.00 | NULL  |
|  1 | SIMPLE      | s2    | NULL       | eq_ref | PRIMARY       | PRIMARY | 4       | atguigudb1.s1.id |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+--------+---------------+---------+---------+------------------+------+----------+-------+
2 rows in set, 1 warning (0.00 sec)

mysql> 

3、用到函数时，ref的值为func
mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = UPPER(s2.key1);
+----+-------------+-------+------------+------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s2    | NULL       | ALL  | NULL          | NULL     | NULL    | NULL | 9895 |   100.00 | NULL                  |
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | func |    1 |   100.00 | Using index condition |
+----+-------------+-------+------------+------+---------------+----------+---------+------+------+----------+-----------------------+
2 rows in set, 1 warning (0.00 sec)

mysql>

9. rows

预估需要读取的条数，值越小越好

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |  410 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.01 sec)

mysql>

10. filtered

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

1、如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用到对应索引的搜索条件外，
其他搜索条件的记录有多少条。
如下面查询，使用key1条件查询索引后，预估得到410条记录，
但加上common_field条件过滤后，预估只剩下41条记录（10%）
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |  410 |    10.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

2、对于单表查询来说，这个filtered列的值没什么意义，
我们更关注在连接查询中驱动表对应的执行计划记录的filtered值，
它决定了被驱动表要执行的次数(即: rows * filtered%)
如下：预估驱动表s1查出共9895条，而加上s1.common_field = 'a'查询条件后预估剩下989，
此时预估被驱动表s2要执行的989次查询
mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref                | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | idx_key1      | NULL     | NULL    | NULL               | 9895 |    10.00 | Using where |
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key1      | idx_key1 | 303     | atguigudb1.s1.key1 |    1 |   100.00 | NULL        |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
2 rows in set, 1 warning (0.00 sec)

mysql>

11. Extra（重要）

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

1、'No tables used' 
当查询语句的没有FROM子句时将会提示该额外信息
mysql> EXPLAIN SELECT NOW();
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

mysql>

2、'Impossible WHERE'
查询语句的WHERE子句永远为FALSE时将会提示该额外信息
mysql> EXPLAIN SELECT * FROM s1 WHERE 1 != 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra            |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | Impossible WHERE |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

3、'Using where'
当我们使用 全表扫描 来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，
在Extra列中会提示上述额外信息。
mysql> EXPLAIN SELECT * FROM s1 WHERE common_field = 'a';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |    10.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

当使用索引访问来执行对某个表的查询，并且该语句的WHERE子句中
有除了该索引包含的列之外的其他搜索条件时，在Extra列中也会提示上述额外信息。
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' AND common_field = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |    10.00 | Using where |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

4、'No matching min/max row'
当查询列表处有`MIN`或者`MAX`聚合函数，但是并没有符合`WHERE`子句中的搜索条件的记录时，
将会提示该额外信息
mysql> EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                   |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | No matching min/max row |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------------------+
1 row in set, 1 warning (0.00 sec)

当存在符合条件的搜索记录时，提示的额外信息为：'Select tables optimized away'
mysql> EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'oQoUJw';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                        |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | Select tables optimized away |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

5、'Using index'
当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以
使用 覆盖索引 的情况下，在`Extra`列将会提示该额外信息。
比方说下边这个查询中只需要用到idx_key1而不需要回表操作:
mysql> EXPLAIN SELECT key1 FROM s1 WHERE key1 = 'a';
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | const |    1 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------+----------+---------+-------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

6、'Using index condition'
索引下推（ICP）https://www.jianshu.com/p/31ceadace535
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key      | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | s1    | NULL       | range | idx_key1      | idx_key1 | 303     | NULL |  410 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+----------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

mysql> 

7、'Using join buffer'
在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为
其分配一块名叫`join buffer`的内存块来加快查询速度，也就是我们所讲的`基于块的嵌套循环算法`
参考：https://juejin.cn/post/6854573214903828493
mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field = s2.common_field;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | NULL                                       |
|  1 | SIMPLE      | s2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |    10.00 | Using where; Using join buffer (hash join) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+--------------------------------------------+
2 rows in set, 1 warning (0.00 sec)

mysql> 

8、'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;
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref                | rows | filtered | Extra                   |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL     | NULL    | NULL               | 9895 |   100.00 | NULL                    |
|  1 | SIMPLE      | s2    | NULL       | ref  | idx_key1      | idx_key1 | 303     | atguigudb1.s1.key1 |    1 |    10.00 | Using where; Not exists |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------------------+
2 rows in set, 1 warning (0.00 sec)

mysql>

9、'Using union'
如果执行计划的`Extra`列出现了`Using intersect(...)`提示，说明准备使用`Intersect`索引合并的方式执行查询，
括号中的`...`表示需要进行索引合并的索引名称;
如果出现了`Using union(...)`提示，说明准备使用`Union`索引合并的方式执行查询;
出现了`Using sort union(...)`提示，说明准备使用`sort-Union`索引合并的方式执行查询。
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
| id | select_type | table | partitions | type        | possible_keys     | key               | key_len | ref  | rows | filtered | Extra                                       |
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
|  1 | SIMPLE      | s1    | NULL       | index_merge | idx_key1,idx_key3 | idx_key1,idx_key3 | 303,303 | NULL |    2 |   100.00 | Using union(idx_key1,idx_key3); Using where |
+----+-------------+-------+------------+-------------+-------------------+-------------------+---------+------+------+----------+---------------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql>

10、'Zero limit'
当我们的`LIMIT`子句的参数为0时，表示压根儿不打算从表中读出任何记录，将会提示该额外信息
mysql> EXPLAIN SELECT * FROM s1 LIMIT 0;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra      |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | Zero limit |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+------------+
1 row in set, 1 warning (0.00 sec)

mysql>

11、'Using filesort'
很多情况下排序操作无法使用到索引，
只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）进行排序，
MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名: 'filesort')
如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的`Extra`列中显示'Using filesort'
mysql> EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

mysql>

12、'Using temporary'
在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，
比如我们在执行许多包含`DISTINCT`、`GROUP BY`、`UNION`等子句的查询过程中，
如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。
如果查询中使用到了内部的临时表，在执行计划的`Extra`列将会显示'Using temporary'
mysql> EXPLAIN SELECT DISTINCT common_field FROM s1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | Using temporary |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
1 row in set, 1 warning (0.00 sec)

mysql> EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
|  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | Using temporary |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
1 row in set, 1 warning (0.00 sec)

mysql>

执行计划中出现'Using temporary'并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，
所以我们`最好能使用索引来替代掉使用临时表`。

12. 小结

• EXPLAIN不考虑各种Cache
• EXPLAIN不能显示MySQL在执行查询时所作的优化工作
• EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况

• 部分统计信息是估算的，并非精确值

  7. EXPALIN的进一步使用

  7.1、EXPALIN的四种输出格式

  这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式，JSON格式，TREE格式 以及 可视化输出。用户可以根据需要选择适用于自己的格式。

  1、传统格式

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

  mysql> EXPLAIN SELECT DISTINCT common_field FROM s1;
  +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
  | id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra           |
  +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
  |  1 | SIMPLE      | s1    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 9895 |   100.00 | Using temporary |
  +----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-----------------+
  1 row in set, 1 warning (0.00 sec)
  

  2、JSON格式

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

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

  EXPLAIN FORMAT=JSON SELECT ....
  

• EXPLAIN的Column与JSON的对应关系：(来源于MySQL 5.7文档）

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

mysql> 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,
    "cost_info": {
      "query_cost": "2102.20"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "s1",
          "access_type": "ALL",
          "possible_keys": [
            "idx_key1"
          ],
          "rows_examined_per_scan": 9895,
          "rows_produced_per_join": 989,
          "filtered": "10.00",
          "cost_info": {
            "read_cost": "914.80",
            "eval_cost": "98.95",
            "prefix_cost": "1013.75",
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ],
          "attached_condition": "((`atguigudb1`.`s1`.`common_field` = 'a') and (`atguigudb1`.`s1`.`key1` is not null))"
        }
      },
      {
        "table": {
          "table_name": "s2",
          "access_type": "eq_ref",
          "possible_keys": [
            "idx_key2"
          ],
          "key": "idx_key2",
          "used_key_parts": [
            "key2"
          ],
          "key_length": "5",
          "ref": [
            "atguigudb1.s1.key1"
          ],
          "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": "989.50",
            "eval_cost": "98.95",
            "prefix_cost": "2102.20",
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "id",
            "key1",
            "key2",
            "key3",
            "key_part1",
            "key_part2",
            "key_part3",
            "common_field"
          ]
        }
      }
    ]
  }
}
1 row in set, 2 warnings (0.00 sec)

mysql>

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=2102.20 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=1.00 rows=1)

1 row in set, 1 warning (0.00 sec)

mysql>

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;
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key      | key_len | ref                | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
|  1 | SIMPLE      | s2    | NULL       | ALL  | idx_key1      | NULL     | NULL    | NULL               | 9895 |    90.00 | Using where |
|  1 | SIMPLE      | s1    | NULL       | ref  | idx_key1      | idx_key1 | 303     | atguigudb1.s2.key1 |    1 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------+----------+---------+--------------------+------+----------+-------------+
2 rows in set, 1 warning (0.00 sec)

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

ERROR: 
No query specified

mysql>

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

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

OPTINIZER_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
• REPALCE
• UPDATE
• DELETE

测试，执行如下SQL：

select * from student where id < 10;

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

mysql> select * from information_schema.optimizer_trace\G
  *************************** 1. row ***************************
  //第一部分，查询的SQL语句
  QUERY: select * from student where id < 10
    //第二部分，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": 3732078,
                        "cost": 383684
                        } /* 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,
                            "in_memory": 9.56572e-05,
                            "rows": 9,
                            "cost": 1.91984,
                            "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.91984,
                        "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.81984,
                          "chosen": true
                          }
                      ] /* considered_access_paths */
                    } /* best_access_path */,
                    "condition_filtering_pct": 100, //行过滤百分比
                    "rows_for_plan": 9,
                    "cost_for_plan": 2.81984,
                    "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 */
    }
//第三部分：跟踪信息过长时，被截断的跟踪信息的字节数。
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0 //丢失的超出最大容量的字节
   //第四部分：执行跟踪语句的用户是否有查看对象的权限。当不具有权限时，
  //该列信息为1且TRACE字段为空，一般在调用带有SQL SECURITY DEFINER的视图或者是存储过程的情况下，会出现此问题。
  INSUFFICIENT_PRIVILEGES: 0 //缺失权限
    1 row in set (0.00 sec)

mysql>

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视图使用场景

    索引情况 ```sql

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

**表相关**
```sql
#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';

语句相关

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

IO相关

#1．查看消耗磁盘I0的文件
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;

InnoDB相关

#1．行锁阻塞情况
SELECT * FROM sys.innodb_lock_waits;

风险提示： 通过sys库去查询时，MySQL会消耗大量资源去收集相关信息，严重的可能会导致业务请求被阻塞，从而引起故障。建议生产上不要频繁的去查询sys或者performance_schema、information_schema来完成监控、巡检等工作。