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

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

在数据库调优中，我们的目标是 响应时间快，吞吐量更大。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。当我们遇到数据库调优问题的时候，该如何思考呢？这里把思考的流程整理成下面这张图。整个流程划分成了 观察（Show status） 和 行动（Action） 两个部分。字母 S 的部分代表观察（会使用相应的分析工具），字母 A 代表的部分是行动（对应分析可以采取的行动）。
image.png
我们可以通过观察了解数据库整体的运行状态，通过性能分析工具可以让我们了解执行慢的SQL 都有哪些，查看具体的 SQL 执行计划，甚至是 SQL 执行中的每一步的成本代价，这样才能定位问题所在，找到了问题，再采取相应的行动。
详细解释一下这张图：
首先在 S1 部分，我们需要观察服务器的状态是否存在周期性的波动。如果存在周期性波动，有可能是周期性节点的原因，比如双十一、促销活动等。这样的话，我们可以通过 A1这一步骤解决，也就是加缓存，或者更改缓存失效策略。
如果缓存策略没有解决，或者不是周期性波动的原因，我们就需要进一步分析查询延迟和卡顿的原因。接下来进入 S2 这一步，我们需要开启慢查询。慢查询可以帮我们定位执行慢的SQL 语句。我们可以通过设置 long_query_time 参数定义“慢”的阈值，如果 SQL 执行时间超过了 long_query_time，则会认为是慢查询。当收集上来这些慢查询之后，我们就可以通过分析工具对慢查询日志进行分析。
在 S3 这一步骤中，我们就知道了执行慢的 SQL，这样就可以针对性地用 EXPLAIN 查看对应 SQL 语句的执行计划，或者使用 show profile 查看 SQL 中每一个步骤的时间成本。这样我们就可以了解 SQL 查询慢是因为执行时间长，还是等待时间长。
如果是 SQL 等待时间长，我们进入 A2 步骤。在这一步骤中，我们可以调优服务器的参数，比如适当增加数据库缓冲池等。如果是 SQL 执行时间长，就进入 A3 步骤，这一步中我们需要考虑是索引设计的问题？还是查询关联的数据表过多？还是因为数据表的字段设计问题导致了这一现象。然后在这些维度上进行对应的调整。
如果 A2 和 A3 都不能解决问题，我们需要考虑数据库自身的 SQL 查询性能是否已经达到了瓶颈，如果确认没有达到性能瓶颈，就需要重新检查，重复以上的步骤。如果已经达到了性能瓶颈，进入 A4 阶段，需要考虑增加服务器，采用读写分离的架构，或者考虑对数据库进行分库分表，比如垂直分库、垂直分表和水平分表等。

以上就是数据库调优的流程思路。如果我们发现执行 SQL 时存在不规则延迟或卡顿的时候，就可以采用分析工具帮我们定位有问题的 SQL，这三种分析工具你可以理解是 SQL 调优的三个步骤：慢查询、EXPLAIN 和 SHOW PROFILING
小结：
image.png

2. 查看系统性能参数

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

  1. 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服务器的连接次数，则可以执行如下语句

  1. SHOW STATUS LIKE 'Connections';

若查询服务器的工作时间，则可以执行如下语句：

  1. SHOW STATUS LIKE 'Uptime';

若查询MySQL服务器的慢查询次数，则可以执行如下语句

  1. SHOW STATUS LIKE 'Slow_queries';

慢查询次数参数可以结合慢查询日志找出慢查询语句，然后针对慢查询语句进行表结构优化或者查询语句优化。再比如，如下的指令可以查看相关的指令情况：

  1. SHOW STATUS LIKE 'Innodb_rows_%';

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

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

  1. CREATE TABLE `student_info` (
  2.     `id` INT(11) NOT NULL AUTO_INCREMENT,
  3.     `student_id` INT NOT NULL ,
  4.     `name` VARCHAR(20) DEFAULT NULL,
  5.     `course_id` INT NOT NULL ,
  6.     `class_id` INT(11) DEFAULT NULL,
  7.     `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  8.     PRIMARY KEY (`id`)
  9. ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

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

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

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

  1. mysql> SHOW STATUS LIKE 'last_query_cost';
  2. +-----------------+----------+
  3. | Variable_name  | Value  |
  4. +-----------------+----------+
  5. | Last_query_cost | 1.000000 |
  6. +-----------------+----------+

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

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

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

  1. mysql> SHOW STATUS LIKE 'last_query_cost';
  2. +-----------------+-----------+
  3. | Variable_name  | Value   |
  4. +-----------------+-----------+
  5. | Last_query_cost | 21.134453 |
  6. +-----------------+-----------+

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

  • 位置决定效率。如果页就在数据库缓冲池中，那么效率是最高的，否则还需要从内存或者磁盘中进行读取，当然针对单个页的读取来说，如果页存在于内存中，会比在磁盘中读取效率高很多。
  • 批量决定效率。如果我们从磁盘中对单一页进行随机读，那么效率是很低的(差不多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数据库没有开启慢查询日志，需要我们手动来设置这个参数。如果不是调优需要的话，一般不建议启动该参数。因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件。

4.1 开启慢查询日志参数

  1. 开启slow_query_log

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

  1. mysql > show variables like '%slow_query_log';

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

  1. mysql > set global slow_query_log='ON';

然后我们再来查看下慢查询日志是否开启，以及慢查询日志文件的位置：
image.png
你能看到这时慢查询分析已经开启，同时文件保存在 /var/lib/mysql/atguigu02-slow.log 文件中

  1. 修改long_query_time阈值

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

  1. mysql > show variables like '%long_query_time%';

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

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

image.png
补充：配置文件中一并设置参数
如下的方式相较于前面的命令行方式，可以看做是永久设置的方式。
修改my.cnf文件，[mysqld]下添加增加或修改参数long_query_time、slow_query_log和slow_query_log_file后，然后重启MySQL服务器。

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

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

4.2 查看慢查询数目

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

  1. SHOW GLOBAL STATUS LIKE '%Slow_queries%';

4.3 案例演示

步骤1. 建表

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

步骤2：设置参数 log_bin_trust_function_creators
创建函数，假如报错：This function has none of DETERMINISTIC......

  • 命令开启：允许创建函数设置：
    1. set global log_bin_trust_function_creators=1;   # 不加global只是当前窗口有效。
    步骤3：创建函数
    随机产生字符串：（同上一章）
    1. DELIMITER //
    2. CREATE FUNCTION rand_string(n INT)
    3. RETURNS VARCHAR(255) #该函数会返回一个字符串
    4. BEGIN
    5. DECLARE chars_str VARCHAR(100) DEFAULT
    6. 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
    7. DECLARE return_str VARCHAR(255) DEFAULT '';
    8. DECLARE i INT DEFAULT 0;
    9. WHILE i < n DO
    10.  SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
    11.  SET i = i + 1;
    12. END WHILE;
    13. RETURN return_str;
    14. END //
    15. DELIMITER ;
    16. #测试
    17. SELECT rand_string(10);
    产生随机数值：（同上一章） 
    1. DELIMITER //
    2. CREATE FUNCTION rand_num (from_num INT ,to_num INT) RETURNS INT(11)
    3. BEGIN 
    4. DECLARE i INT DEFAULT 0; 
    5. SET i = FLOOR(from_num +RAND()*(to_num - from_num+1))  ;
    6. RETURN i; 
    7. END //
    8. DELIMITER ;
    9. #测试：
    10. SELECT rand_num(10,100);
    步骤4：创建存储过程 
    1. DELIMITER //
    2. CREATE PROCEDURE insert_stu1(  START INT , max_num INT )
    3. BEGIN 
    4. DECLARE i INT DEFAULT 0; 
    5. SET autocommit = 0;   #设置手动提交事务
    6. REPEAT  #循环
    7. SET i = i + 1;  #赋值
    8. INSERT INTO student (stuno, NAME ,age ,classId ) VALUES
    9. ((START+i),rand_string(6),rand_num(10,100),rand_num(10,1000)); 
    10. UNTIL i = max_num 
    11. END REPEAT; 
    12. COMMIT;  #提交事务
    13. END //
    14. DELIMITER ;
    步骤5：调用存储过程
    1. #    调用刚刚写好的函数, 4000000条记录,从100001号开始
    2. CALL insert_stu1(100001,4000000);

    4.4 测试及分析

  1. 测试

    1. mysql> SELECT * FROM student WHERE stuno = 3455655;
    2. +---------+---------+--------+------+---------+
    3. | id   | stuno  | name  | age | classId |
    4. +---------+---------+--------+------+---------+
    5. | 3523633 | 3455655 | oQmLUr |  19 |    39 |
    6. +---------+---------+--------+------+---------+
    7. 1 row in set (2.09 sec)
    8. mysql> SELECT * FROM student WHERE name = 'oQmLUr';
    9. +---------+---------+--------+------+---------+
    10. | id   | stuno  | name  | age | classId |
    11. +---------+---------+--------+------+---------+
    12. | 1154002 | 1243200 | OQMlUR |  266 |    28 |
    13. | 1405708 | 1437740 | OQMlUR |  245 |   439 |
    14. | 1748070 | 1680092 | OQMlUR |  240 |   414 |
    15. | 2119892 | 2051914 | oQmLUr |  17 |    32 |
    16. | 2893154 | 2825176 | OQMlUR |  245 |   435 |
    17. | 3523633 | 3455655 | oQmLUr |  19 |    39 |
    18. +---------+---------+--------+------+---------+
    19. 6 rows in set (2.39 sec)

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

  2. 分析

    1. show status like 'slow_queries';

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

    1. mysql> show variables like 'min%';
    2. +------------------------+---+
    3. | Variable_name | Value |
    4. +------------------------+---+
    5. | min_examined_row_limit | 0 |
    6. +------------------------+---+
    7. 1 row in set, 1 warning (0.00 sec)

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

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

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

    1. mysqldumpslow --help

    image.png
    mysqldumpslow 命令的具体参数如下：

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

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

  1. [root@bogon ~]# mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.log
  3. Reading mysql slow query log from /var/lib/mysql/atguigu01-slow.log
  4. Count: 1  Time=2.39s (2s)  Lock=0.00s (0s) Rows=13.0 (13), root[root]@localhost
  5.  SELECT * FROM student WHERE name = 'S'
  7. Count: 1  Time=2.09s (2s)  Lock=0.00s (0s) Rows=2.0 (2), root[root]@localhost
  8.  SELECT * FROM student WHERE stuno = N
  10. Died at /usr/bin/mysqldumpslow line 162, <> chunk 2.

工作常用参考：

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

4.6 关闭慢查询日志

MySQL服务器停止慢查询日志功能有两种方法：
方式1：永久性方式
修改my.cnf或者my.ini文件，把[mysqld]组下的slow_query_log值设置为OFF，修改保存后，再重启MySQL服务，即可生效

  1. [mysqld] 
  2. slow_query_log=OFF

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

  1. [mysqld] 
  2. #slow_query_log =OFF

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

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

可以看到，MySQL系统中的慢查询日志是关闭的
方式2：临时性方式
使用SET语句来设置。

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

    1. SET GLOBAL slow_query_log=off;

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

    1. SHOW VARIABLES LIKE '%slow%'; 
    2. #以及 
    3. SHOW VARIABLES LIKE '%long_query_time%';

    4.7 删除慢查询日志

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

    1. SHOW VARIABLES LIKE 'slow_query_log%'；

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

    1. mysqladmin -uroot -p flush-logs slow

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

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

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

  1. mysql > show variables like 'profiling';

image.png
通过设置 profiling=’ON’ 来开启 show profile：

  1. mysql > set profiling = 'ON';

image.png
然后执行相关的查询语句。接着看下当前会话都有哪些 profiles，使用下面这条命令：

  1. mysql > show profiles;

image.png
你能看到当前会话一共有2个查询。如果我们想要查看最近一次查询的开销，可以使用：

  1. mysql > show profile;

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

  1. mysql> show profile cpu,block io for query 2;

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

show profile的常用查询参数：

  • ALL：显示所有的开销信息
  • BLOCK IO：显示块IO开销
  • CONTEXT SWITCHES：上下文切换开销
  • CPU：显示CPU开销信息
  • IPC：显示发送和接收开销信息
  • MEMORY：显示内存开销信息
  • PAGE FAULTS：显示页面错误开销信息
  • SOURCE：显示和Source_function、Source_file、Source_line相关的开销信息
  • SWAPS：显示交换次数开销信息

日常开发需要注意的结论：

  • converting HEAP to MyISAM：查询结果太大，内存不够，数据往磁盘上搬了。
  • Creating tmp table：创建临时表。先拷贝数据到临时表，用完后再删除临时表。
  • Copying to tmp table on disk：把内存中临时表复制到磁盘上，警惕！
  • 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. 能做什么?
  • 表的读取顺序
  • 数据读取操作的操作类型
  • 哪些索引可以使用
  • 哪些索引被实际使用
  • 表之间的引用
  • 每张表有多少行被优化器查询

MySQL 5.7官方文档
MySQL 8.0官方文档
版本情况

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

image.png

6.2 基本语法

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

  1. EXPLAIN SELECT select_options 
  3. 或者
  5. DESCRIBE SELECT select_options

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

  1. mysql> EXPLAIN SELECT 1;

image.png
输出的上述信息就是所谓的执行计划，在这个执行计划的辅助下，我们需要知道应该怎样改进自己的查询语句以使查询执行起来更高效。其实除了以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 数据准备

  1. 建表

    1. CREATE TABLE s1 (
    2.   id INT AUTO_INCREMENT,
    3.   key1 VARCHAR(100),
    4.   key2 INT,
    5.   key3 VARCHAR(100),
    6.   key_part1 VARCHAR(100),
    7.   key_part2 VARCHAR(100),
    8.   key_part3 VARCHAR(100),
    9.   common_field VARCHAR(100),
    10.    PRIMARY KEY (id),
    11.    INDEX idx_key1 (key1),
    12.    UNIQUE INDEX idx_key2 (key2),
    13.    INDEX idx_key3 (key3),
    14.    INDEX idx_key_part(key_part1, key_part2, key_part3)
    15. ) ENGINE=INNODB CHARSET=utf8;
    1. CREATE TABLE s2 (
    2.   id INT AUTO_INCREMENT,
    3.   key1 VARCHAR(100),
    4.   key2 INT,
    5.   key3 VARCHAR(100),
    6.   key_part1 VARCHAR(100),
    7.   key_part2 VARCHAR(100),
    8.   key_part3 VARCHAR(100),
    9.   common_field VARCHAR(100),
    10.    PRIMARY KEY (id),
    11.    INDEX idx_key1 (key1),
    12.    UNIQUE INDEX idx_key2 (key2),
    13.    INDEX idx_key3 (key3),
    14.    INDEX idx_key_part(key_part1, key_part2, key_part3)
    15. ) ENGINE=INNODB CHARSET=utf8;

  2. 设置参数 log_bin_trust_function_creators

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

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

  1. 创建函数

    1. DELIMITER //
    2. CREATE FUNCTION rand_string1(n INT)
    3.  RETURNS VARCHAR(255) #该函数会返回一个字符串
    4. BEGIN
    5. DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
    6.  DECLARE return_str VARCHAR(255) DEFAULT '';
    7.  DECLARE i INT DEFAULT 0;
    8.  WHILE i < n DO
    9.      SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
    10.      SET i = i + 1;
    11.  END WHILE;
    12.  RETURN return_str;
    13. END //
    14. DELIMITER ;

  2. 创建存储过程

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

  1. DELIMITER //
  2. CREATE PROCEDURE insert_s1 (IN min_num INT (10),IN max_num INT (10))
  3. BEGIN
  4.     DECLARE i INT DEFAULT 0;
  5.     SET autocommit = 0;
  6.     REPEAT
  7.     SET i = i + 1;
  8.     INSERT INTO s1 VALUES(
  9.      (min_num + i),
  10.      rand_string1(6),
  11.      (min_num + 30 * i + 5),
  12.      rand_string1(6),
  13.      rand_string1(10),
  14.      rand_string1(5),
  15.      rand_string1(10),
  16.      rand_string1(10));
  17.     UNTIL i = max_num
  18.     END REPEAT;
  19.     COMMIT;
  20. END //
  21. DELIMITER ;

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

  1. DELIMITER //
  2. CREATE PROCEDURE insert_s2 (IN min_num INT (10),IN max_num INT (10))
  3. BEGIN
  4.     DECLARE i INT DEFAULT 0;
  5.     SET autocommit = 0;
  6.     REPEAT
  7.     SET i = i + 1;
  8.     INSERT INTO s2 VALUES((min_num + i),
  9.         rand_string1(6),
  10.         (min_num + 30 * i + 5),
  11.         rand_string1(6),
  12.         rand_string1(10),
  13.         rand_string1(5),
  14.         rand_string1(10),
  15.         rand_string1(10));
  16.     UNTIL i = max_num
  17.     END REPEAT;
  18.     COMMIT;
  19. END //
  20. DELIMITER ;
  1. 调用存储过程

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

  1. CALL insert_s1(10001,10000);

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

  1. CALL insert_s2(10001,10000);

6.4 EXPLAIN各列作用

1. table

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

  1. mysql> EXPLAIN SELEC * FROM s1;

image.png
这个查询语句只涉及对s1表的单表查询，所以EXPLAIN输出中只有一条记录，其中的table列的值是s1，表名这条记录是用来说明对s1表的单表访问方法的。下边我们看一个连接查询的执行计划：

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

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

2. id

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

  1. SELECT * FROM s1 WHERE key1 = 'a';

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

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

但是下边两种情况下在一条查询语句中会出现多个SELECT关键字：

  • 查询中包含子查询的情况

比如下边这个查询语句中就包含2个SELECT关键字：

  1. SELECT * FROM s1 WHERE key1 IN (SELECT * FROM s2);
  • 查询中包含UNION语句的情况

比如下边这个查询语句中也包含2个SELECT关键字：

  1. SELECT * FROM s1  UNION SELECT * FROM s2;

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

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

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

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

image.png
可以看到，上述连接查询中参与连接的s1和s2表分别对应一条记录，但是这两条记录对应的id值都是1。这里需要大家记住的是，在连接查询的执行计划中，每个表都会对应一条记录，这些记录的id列的值是相同的，出现在前边的表表示驱动表，出现在后边的表表示被驱动表。所以从上边的EXPLAIN输出中我们可以看出，查询优化器准备让s1表作为驱动表，让s2表作为被驱动表来执行查询。对于包含子查询的查询语句来说，就可能涉及多个SELECT关键字，所以在包含子查询的查询语句的执行计划中，每个SELECT关键字都会对应一个唯一的id值，比如这样：

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

image.png
从输出结果中我们可以看到，s1表在外层查询中，外层查询有一个独立的SELECT关键字，所以第一条记录的id值就是1，s2表在子查询中，子查询有一个独立的SELECT关键字，所以第二条记录的id值就是2。但是这里大家需要特别注意，查询优化器可能对涉及子查询的查询语句进行重写，从而转换为连接查询。所以如果我们想知道查询优化器对某个包含子查询的语句是否进行了重写，直接查看执行计划就好了，比如说：

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

image.png
可以看到，虽然我们的查询语句是一个子查询，但是执行计划中s1和s2表对应的记录的id值全部是1，这就表明了查询优化器将子查询转换为了连接查询。对于包含UNION子句的查询语句来说，每个SELECT关键字对应一个id值也是没错的，不过还是有点儿特别的东西，比方说下边这个查询：

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

image.png
这个语句的执行计划的第三条记录是个什么鬼？为毛id值是NULL，而且table列长的也怪怪的？大家别忘了UNION子句是干嘛用的，它会把多个查询的结果集合并起来并对结果集中的记录进行去重，怎么去重呢？MySQL使用的是内部的临时表。正如上边的查询计划中所示，UNION子句是为了把id为1的查询和id为2的查询的结果集合并起来并去重，所以在内部创建了一个名为的临时表（就是执行计划第三条记录的table列的名称），id为NULL表明这个临时表是为了合并两个查询的结果集而创建的。
跟UNION对比起来，UNION ALL就不需要为最终的结果集进行去重，它只是单纯的把多个查询的结果集中的记录合并成一个并返回给用户，所以也就不需要使用临时表。所以在包含UNION ALL子句的查询的执行计划中，就没有那个id为NULL的记录，如下所示：

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

image.png
小结:

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

    3. select_type

    一条大的查询语句里边可以包含若干个SELECT关键字，每个SELECT关键字代表着一个小的查询语句，而每个SELECT关键字的FROM子句中都可以包含若干张表（这些表用来做连接查询），每一张表都对应着执行计划输出中的一条记录，对于在同一个SELECT关键字中的表来说，它们的id值是相同的。
    MySQL为每一个SELECT关键字代表的小查询都定义了一个称之为select_type的属性，意思是我们只要知道了某个小查询的select_type属性，就知道了这个小查询在整个大查询中扮演了一个什么角色，我们还是先来看一下select_type都能取哪些值（为了精确起见，我们直接使用文档中的英文做简要描述，随后会进行详细解释的）：
名称 描述
SIMPLE Simple SELECT (not using UNION or subqueries)
PRIMARY Outermost SELECT
UNION Second or later SELECT statement in a UNION
UNION RESULT Result of a UNION
SUBQUERY First SELECT in subquery
DEPENDENT SUBQUERY First SELECT in subquery, dependent on outer query
DEPENDENT UNION Second or later SELECT statement in a UNION, dependent on outer query
DERIVED Derived table
MATERIALIZED Materialized subquery
UNCACHEABLE SUBQUERY A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

具体分析如下：

  • SIMPLE

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

  1. mysql> EXPLAIN SELECT * FROM s1;

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

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

image.png

  • PRIMARY

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

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

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

  • UNION

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

  • UNION RESULT

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

  • SUBQUERY

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

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

image.png
可以看到，外层查询的select_type就是PRIMARY，子查询的select_type就是SUBQUERY。需要大家注意的是，由于select_type为SUBQUERY的子查询由于会被物化，所以只需要执行一遍。

  • DEPENDENT SUBQUERY

如果包含子查询的查询语句不能够转为对应的semi-join的形式，并且该子查询是相关子查询，则该子查询的第一个SELECT关键字代表的那个查询的select_type就是DEPENDENT SUBQUERY，比如下边这个查询：

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

image.png
需要大家注意的是，select_type为DEPENDENT SUBQUERY的查询可能会被执行多次。

  • DEPENDENT UNION

在包含UNION或者UNION ALL的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的select_type的值就是DEPENDENT UNION。说的有些绕哈，比方说下边这个查询：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = 'a' UNION SELECT key1 FROM s1 WHERE key1 = 'b');

image.png
这个查询比较复杂啊，大查询里包含了一个子查询，子查询里又是由UNION连起来的两个小查询。从执行计划中可以看出来，SELECT key1 FROM s2 WHERE key1 = 'a'这个小查询由于是子查询中第一个查询，所以它的select_type是DEPENDENT SUBQUERY，而SELECT key1 FROM s1 WHERE key1 = 'b'这个查询的select_type就是DEPENDENT UNION。

  • DERIVED

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

  1. mysql> EXPLAIN SELECT * FROM (SELECT key1, count(*) as c FROM s1 GROUP BY key1) AS derived_s1 where c > 1;

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

  • MATERIALIZED

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

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2);

image.png
执行计划的第三条记录的id值为2，说明该条记录对应的是一个单表查询，从它的select_type值为MATERIALIZED可以看出，查询优化器是要把子查询先转换成物化表。然后看执行计划的前两条记录的id值都为1，说明这两条记录对应的表进行连接查询，需要注意的是第二条记录的table列的值是，说明该表其实就是id为2对应的子查询执行之后产生的物化表，然后将s1和该物化表进行连接查询。

  • UNCACHEABLE SUBQUERY 和 UNCACHEABLE UNION

不常用

4. partitions (可略)

  • 代表分区表中的命中情况，非分区表，该项为NULL。一般情况下我们的查询语句的执行计划的partitions列的值都是NULL
  • 官方地址

如果想详细了解，可以如下方式测试。创建分区表：

  1. -- 创建分区表，
  2. -- 按照id分区，id<100 p0分区，其他p1分区
  3. CREATE TABLE user_partitions (id INT auto_increment,
  4.     NAME VARCHAR(12),PRIMARY KEY(id))
  5.       PARTITION BY RANGE(id)(
  6.     PARTITION p0 VALUES less than(100),
  7.     PARTITION p1 VALUES less than MAXVALUE
  8.  );
  9.                                           );

image.png

  1. DESC SELECT * FROM user_partitions WHERE id>200;

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

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

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

  1. mysql> CREATE TABLE t(i int) Engine=MyISAM; Query OK, 0 rows affected (0.05 sec) 
  2. mysql> INSERT INTO t VALUES(1); Query OK, 1 row affected (0.01 sec)

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

  1. mysql> EXPLAIN SELECT * FROM t;

image.png
可以看到type列的值就是system了。测试：可以把表改成使用InnoDB存储引擎，试试看执行计划的type列是什么。ALL

  • const

这个我们前边唠叨过，就是当我们根据主键或者唯一二级索引列(唯一索引)与常数进行等值匹配时，对单表的访问方法就是const，比如：

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

image.png

  • eq_ref

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

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

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

  • ref

当通过普通的二级索引列与常量进行等值匹配时来查询某个表，那么对该表的访问方法就可能是ref，最开始举过例子了，就不重复举例了。

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

image.png

  • fulltext：全文索引
  • ref_or_null

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

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key1 IS NULL;

image.png

  • index_merge

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

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

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

  • unique_subquery

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

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

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

  • index_subquery

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

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

image.png

  • range

如果使用索引获取某些范围区间的记录，那么就可能使用到range访问方法，比如下边的这个查询：

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

image.png
或者

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

image.png

  • index

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

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

image.png
上述查询中的搜索列表中只有key_part2一个列，而且搜索条件中也只有key_part3一个列，这两个列又恰好包含在idx_key_part这个索引中，可是搜索条件key_part3不能直接使用该索引进行ref或者range方式的访问，只能扫描整个idx_key_part索引的记录，所以查询计划的type列的值就是index。再一次强调，对于使用InnoDB存储引擎的表来说，二级索引的记录只包含索引列和主键列的值，而聚簇索引中包含用户定义的全部列以及一些隐藏列，所以扫描二级索引的代价比直接全表扫描，也就是扫描聚簇索引的代价更低一些。

  • ALL
    1. mysql> EXPLAIN SELECT * FROM s1;
    image.png
    一般来说，这些访问方法按照我们介绍它们的顺序性能依次变差。其中除了All这个访问方法外，其余的访问方法都能用到索引，除了index_merge访问方法外，其余的访问方法都最多只能用到一个索引。

小结：
结果值从最好到最坏依次是： 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列表示实际用到的索引有哪些，比方说下边这个查询：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key3 = 'a';

image.png
上述执行计划的possible_keys列的值是idx_key1，idx_key3，表示该查询可能使用到idx_key1，idx_key3两个索引，然后key列的值是idx_key3，表示经过查询优化器计算使用不同索引的成本后，最后决定使用idx_key3来执行查询比较划算。
不过有一点比较特别，就是在使用index访问方法来查询某个表时，possible_keys列是空的，而key列展示的是实际使用到的索引，比如这样：

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

image.png
另外需要注意的一点是，possible_keys列中的值并不是越多越好，可能使用的索引越多，查询优化器计算查询成本时就得花费更长时间，所以如果可以的话，尽量删除那些用不到的索引。

7. key_len ☆

key_len列表示当优化器决定使用某个索引执行查询时，该索引记录的最大长度，它是由这三个部分构成的：

  • 对于使用固定长度类型的索引列来说，它实际占用的存储空间的最大长度就是该固定值，对于指定字符集的变长类型的索引列来说，比如某个索引列的类型是VARCHAR(100)，使用的字符集是utf8，那么该列实际占用的最大存储空间就是100 × 3 = 300个字节。
  • 如果该索引列可以存储NULL值，则key_len比不可以存储NULL值时多1个字节。
  • 对于变长字段来说，都会有2个字节的空间来存储该变长列的实际长度。

比如下边这个查询：

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

image.png
由于id列的类型是INT，并且不可以存储NULL值，所以在使用该列的索引时key_len大小就是4。当索引列可以存储NULL值时，比如：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key2 = 10126;

image.png
可以看到key_len列就变成了5，比使用id列的索引时多了1。对于可变长度的索引列来说，比如下边这个查询：

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

image.png
由于key1列的类型是VARCHAR(100)，所以该列实际最多占用的存储空间就是300字节，又因为该列允许存储NULL值，所以key_len需要加1，又因为该列是可变长度列，所以key_len需要加2，所以最后ken_len的值就是303。
有的同学可能有疑问：你在前边唠叨InnoDB行格式的时候不是说，存储变长字段的实际长度不是可能占用1个字节或者2个字节么？为什么现在不管三七二十一都用了2个字节？这里需要强调的一点是，执行计划的生成是在MySQL server层中的功能，并不是针对具体某个存储引擎的功能，设计MySQL的大叔在执行计划中输出key_len列主要是为了让我们区分某个使用联合索引的查询具体用了几个索引列，而不是为了准确的说明针对某个具体存储引擎存储变长字段的实际长度占用的空间到底是占用1个字节还是2个字节。比方说下边这个使用到联合索引idx_key_part的查询：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a';

image.png
我们可以从执行计划的key_len列中看到值是303，这意味着MySQL在执行上述查询中只能用到idx_key_part索引的一个索引列，而下边这个查询：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b';

image.png
这个查询的执行计划的ken_len列的值是606，说明执行这个查询的时候可以用到联合索引idx_key_part的两个索引列。
练习：
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

    当使用索引列等值匹配的条件去执行查询时，也就是在访问方法是const、eq_ref、ref、ref_or_null、unique_subquery、index_subquery其中之一时，ref列展示的就是与索引列作等值匹配的东东是个啥，比如只是一个常数或者是某个列。大家看下边这个查询：

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

    image.png
    可以看到ref列的值是const，表明在使用idx_key1索引执行查询时，与key1列作等值匹配的对象是一个常数，当然有时候更复杂一点：

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

    image.png
    可以看到对被驱动表s2的访问方法是eq_ref，而对应的ref列的值是xiaohaizi.s1.id，这说明在对被驱动表进行访问时会用到PRIMARY索引，也就是聚簇索引与一个列进行等值匹配的条件，于s2表的id作等值匹配的对象就是xiaohaizi.s1.id列（注意这里把数据库名也写出来了）。有的时候与索引列进行等值匹配的对象是一个函数，比方说下边这个查询：

    1. mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);

    image.png
    我们看执行计划的第二条记录，可以看到对s2表采用ref访问方法执行查询，然后在查询计划的ref列里输出的是func，说明与s2表的key1列进行等值匹配的对象是一个函数。

    9. rows ☆

    如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的rows列就代表预计需要扫描的行数。如果使用索引来执行查询时，执行计划的rows列就代表预计扫描的索引记录行数。比如下边这个查询：

    1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';

    image.png
    我们看到执行计划的rows列的值是266，这意味着查询优化器在经过分析使用idx_key1进行查询的成本之后，觉得满足key1 > 'z'这个条件的记录只有266条。

    10. filtered

    之前在分析连接查询的成本时提出过一个condition filtering的概念，就是MySQL在计算驱动表扇出时采用的一个策略：

  • 如果使用的是全表扫描的方式执行的单表查询，那么计算驱动表扇出时需要估计出满足搜索条件的记录到底有多少条。

  • 如果使用的是索引执行的单表扫描，那么计算驱动表扇出的时候需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。

比方说下边这个查询：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';

image.png
从执行计划的key列中可以看出来，该查询使用idx_key1索引来执行查询，从rows列可以看出满足key1 > 'z'的记录有266条。执行计划的filtered列就代表查询优化器预测在这266条记录中，有多少条记录满足其余的搜索条件，也就是common_field = 'a'这个条件的百分比。此处filtered列的值是10.00，说明查询优化器预测在266条记录中有10.00%的记录满足common_field = 'a'这个条件。对于单表查询来说，这个filtered列的值没什么意义，我们更关注在连接查询中驱动表对应的执行计划记录的filtered值，比方说下边这个查询：

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

image.png
从执行计划中可以看出来，查询优化器打算把s1当作驱动表，s2当作被驱动表。我们可以看到驱动表s1表的执行计划的rows列为9688， filtered列为10.00，这意味着驱动表s1的扇出值就是9688 × 10.00% = 968.8，这说明还要对被驱动表执行大约968次查询。

11. Extra ☆

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

  • No tables used

当查询语句的没有FROM子句时将会提示该额外信息，比如：

  1. mysql> EXPLAIN SELECT 1;

image.png

  • Impossible WHERE

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

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

image.png

  • Using where

不用读取表中的所有信息，仅通过索引就可以获取所需数据，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤。表明使用了where过滤。当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。比如下边这个查询：

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

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

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' AND common_field = 'a';

image.png

  • No matching min/max row

当查询列表处有MIN或者MAX聚集函数，但是并没有符合WHERE子句中的搜索条件的记录时，将会提示该额外信息，比方说：

  1. mysql> EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';

image.png

  • Using index

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

  1. mysql> EXPLAIN SELECT key1 FROM s1 WHERE key1 = 'a'

image.png

  • Using index condition

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

  1. 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 index condition，比如这样：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%b';

image.png

  • Using join buffer (Block Nested Loop)

在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join buffer的内存块来加快查询速度，也就是我们所讲的基于块的嵌套循环算法，比如下边这个查询语句：

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

image.png
可以在对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额外信息，比如这样：

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

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

  • Using intersect(…) 、 Using union(…) 和 Using sort_union(…)

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

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

image.png
其中Extra列就显示了Using intersect(idx_key3,idx_key1)，表明MySQL即将使用idx_key3和idx_key1这两个索引进行Intersect索引合并的方式执行查询。

  • Zero limit

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

  1. mysql> EXPLAIN SELECT * FROM s1 LIMIT 0;

image.png

  • Using filesort

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

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

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

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

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

  • Using temporary

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

  1. mysql> EXPLAIN SELECT DISTINCT common_field FROM s1;

image.png
再比如：

  1. mysql> EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field;

image.png
不知道大家注意到没有，上述执行计划的Extra列不仅仅包含Using temporary提示，还包含Using filesort提示，可是我们的查询语句中明明没有写ORDER BY子句呀？这是因为MySQL会在包含GROUP BY子句的查询中默认添加上ORDER BY子句，也就是说上述查询其实和下边这个查询等价：

  1. EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field ORDER BY common_field;

如果我们并不想为包含GROUP BY子句的查询进行排序，需要我们显式的写上ORDER BY NULL，就像这样：

  1. mysql> EXPLAIN SELECT common_field, COUNT(*) AS amount FROM s1 GROUP BY common_field ORDER BY NULL;

image.png
这回执行计划中就没有Using filesort的提示了，也就意味着执行查询时可以省去对记录进行文件排序的成本了。另外，执行计划中出现Using temporary并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以我们最好能使用索引来替代掉使用临时表，比方说下边这个包含GROUP BY子句的查询就不需要使用临时表：

  1. mysql> EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;

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

  • Start temporary, End temporary

我们前边唠叨子查询的时候说过，查询优化器会优先尝试将IN子查询转换成semi-join，而semi-join又有好多种执行策略，当执行策略为DuplicateWeedout时，也就是通过建立临时表来实现为外层查询中的记录进行去重操作时，驱动表查询执行计划的Extra列将显示Start temporary提示，被驱动表查询执行计划的Extra列将显示End temporary提示，就是这样：

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

image.png

  • LooseScan

在将In子查询转为semi-join时，如果采用的是LooseScan执行策略，则在驱动表执行计划的Extra列就是显示LooseScan提示，比如这样：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE key3 IN (SELECT key1 FROM s2 WHERE key1 > 'z');

image.png

  • FirstMatch(tbl_name)

在将In子查询转为semi-join时，如果采用的是FirstMatch执行策略，则在被驱动表执行计划的Extra列就是显示FirstMatch(tbl_name)提示，比如这样：

  1. mysql> EXPLAIN SELECT * FROM s1 WHERE common_field IN (SELECT key1 FROM s2 where s1.key3 = s2.key3);

image.png

12. 小结

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

    7. EXPLAIN的进一步使用

7.1 EXPLAIN四种输出格式

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

1. 传统格式

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

  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;

image.png

2. JSON格式

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

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

    1. EXPLAIN FORMAT=JSON SELECT ....

  • EXPLAIN的Column与JSON的对应关系：（来源于MySQL 5.7文档） | Column | JSON Name | Meaning | | —- | —- | —- | | id | select_id | The SELECT Identifier | | select_tpye | None | The SELECT type | | table | table_name | The table for the output row | | partitions | partitions | The matching partitions | | type | access_type | The join type | | possible_keys | possible_keys | The possible indexes to choose | | key | key | The index actually chosen | | key_len | key_length | The length of the chosen key | | ref | ref | The columns compared to the index | | rows | rows | Estimate of rows to be examined | | filtered | filtered | Percentage of rows filtered by table condition | | Extra | None | Additional information |

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

  1. mysql> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G
  1. EXPLAIN: {
  2.   "query_block": {
  3.     "select_id": 1,     # 整个查询语句只有1个SELECT关键字，该关键字对应的id号为1
  4.     "cost_info": {
  5.       "query_cost": "3197.16"   # 整个查询的执行成本预计为3197.16
  6.     },
  7.     "nested_loop": [    # 几个表之间采用嵌套循环连接算法执行
  9.     # 以下是参与嵌套循环连接算法的各个表的信息
  10.       {
  11.         "table": {
  12.           "table_name": "s1",   # s1表是驱动表
  13.           "access_type": "ALL",     # 访问方法为ALL，意味着使用全表扫描访问
  14.           "possible_keys": [    # 可能使用的索引
  15.             "idx_key1"
  16.           ],
  17.           "rows_examined_per_scan": 9688,   # 查询一次s1表大致需要扫描9688条记录
  18.           "rows_produced_per_join": 968,    # 驱动表s1的扇出是968
  19.           "filtered": "10.00",  # condition filtering代表的百分比
  20.           "cost_info": {
  21.             "read_cost": "1840.84",     # 稍后解释
  22.             "eval_cost": "193.76",      # 稍后解释
  23.             "prefix_cost": "2034.60",   # 单次查询s1表总共的成本
  24.             "data_read_per_join": "1M"  # 读取的数据量
  25.           },
  26.           "used_columns": [     # 执行查询中涉及到的列
  27.             "id",
  28.             "key1",
  29.             "key2",
  30.             "key3",
  31.             "key_part1",
  32.             "key_part2",
  33.             "key_part3",
  34.             "common_field"
  35.           ],
  37.           # 对s1表访问时针对单表查询的条件
  38.           "attached_condition": "((`xiaohaizi`.`s1`.`common_field` = 'a') and (`xiaohaizi`.`s1`.`key1` is not null))"
  39.         }
  40.       },
  41.       {
  42.         "table": {
  43.           "table_name": "s2",   # s2表是被驱动表
  44.           "access_type": "ref",     # 访问方法为ref，意味着使用索引等值匹配的方式访问
  45.           "possible_keys": [    # 可能使用的索引
  46.             "idx_key2"
  47.           ],
  48.           "key": "idx_key2",    # 实际使用的索引
  49.           "used_key_parts": [   # 使用到的索引列
  50.             "key2"
  51.           ],
  52.           "key_length": "5",    # key_len
  53.           "ref": [      # 与key2列进行等值匹配的对象
  54.             "xiaohaizi.s1.key1"
  55.           ],
  56.           "rows_examined_per_scan": 1,  # 查询一次s2表大致需要扫描1条记录
  57.           "rows_produced_per_join": 968,    # 被驱动表s2的扇出是968（由于后边没有多余的表进行连接，所以这个值也没啥用）
  58.           "filtered": "100.00",     # condition filtering代表的百分比
  60.           # s2表使用索引进行查询的搜索条件
  61.           "index_condition": "(`xiaohaizi`.`s1`.`key1` = `xiaohaizi`.`s2`.`key2`)",
  62.           "cost_info": {
  63.             "read_cost": "968.80",      # 稍后解释
  64.             "eval_cost": "193.76",      # 稍后解释
  65.             "prefix_cost": "3197.16",   # 单次查询s1、多次查询s2表总共的成本
  66.             "data_read_per_join": "1M"  # 读取的数据量
  67.           },
  68.           "used_columns": [     # 执行查询中涉及到的列
  69.             "id",
  70.             "key1",
  71.             "key2",
  72.             "key3",
  73.             "key_part1",
  74.             "key_part2",
  75.             "key_part3",
  76.             "common_field"
  77.           ]
  78.         }
  79.       }
  80.     ]
  81.   }
  82. }

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

  1. "cost_info": { 
  2.   "read_cost": "1840.84", 
  3.   "eval_cost": "193.76", 
  4.   "prefix_cost": "2034.60", 
  5.   "data_read_per_join": "1M" 
  6. }
  • 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 表示在此次查询中需要读取的数据量

大家其实没必要关注MySQL为啥使用这么古怪的方式计算出read_cost和eval_cost，关注prefix_cost是查询s1表的成本就好了。
对于 s2 表的 “cost_info” 部分是这样的：

  1. "cost_info": { 
  2.   "read_cost": "968.80", 
  3.   "eval_cost": "193.76", 
  4.   "prefix_cost": "3197.16", 
  5.   "data_read_per_join": "1M" 
  6. }

由于 s2 表是被驱动表，所以可能被读取多次，这里的 read_cost 和 eval_cost 是访问多次 s2 表后累加起来的值，大家主要关注里边儿的 prefix_cost 的值代表的是整个连接查询预计的成本，也就是单次查询 s1 表和多次查询 s2 表后的成本的和，也就是：
968.80 + 193.76 + 2034.60 = 3197.16

3. TREE格式

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

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

4. 可视化输出

可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图标，即可生成可视化的查询计划。上图按从左到右的连接顺序显示表。红色框表示 全表扫描 ，而绿色框表示使用 索引查找 。对于每个表，显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表的成本。
image.png

7.2 SHOW WARNINGS的使用

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

  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;

image.png

  1. mysql> SHOW WARNINGS\G
  2. *************************** 1. row ***************************
  3.  Level: Note
  4.  Code: 1003
  5. Message: /* select#1 */ select `atguigu`.`s1`.`key1` AS `key1`,`atguigu`.`s2`.`key1`
  6. AS `key1` from `atguigu`.`s1` join `atguigu`.`s2` where ((`atguigu`.`s1`.`key1` =
  7. `atguigu`.`s2`.`key1`) and (`atguigu`.`s2`.`common_field` is not null))
  8. 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。
但是大家一定要注意，我们说的Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句，并不是等价于。也就是说Message字段展示的信息并不是标准的查询语句，在很多情况下并不能直接拿到命令行中运行，它只能帮助我们理解MySQL将如何执行查询语句中的一个参考依据而已

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

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

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

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

  • SELECT
  • INSERT
  • REPLACE
  • UPDATE
  • DELETE
  • EXPLAIN
  • SET
  • DECLARE
  • CASE
  • IF
  • RETURN
  • CALL

测试：执行如下SQL语句

  1. select * from student where id < 10;

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

  1. select * from information_schema.optimizer_trace\G
  1. *************************** 1. row ***************************
  2.  //第1部分：查询语句
  3.  QUERY: select * from student where id < 10
  4.  //第2部分：QUERY字段对应语句的跟踪信息
  5.  TRACE: {
  6.  "steps": [
  7.  {
  8.    "join_preparation": {  //预备工作
  9.     "select#": 1,
  10.     "steps": [
  11.     {
  12.       "expanded_query": "/* select#1 */ select `student`.`id` AS
  13. `id`,`student`.`stuno` AS `stuno`,`student`.`name` AS `name`,`student`.`age` AS
  14. `age`,`student`.`classId` AS `classId` from `student` where (`student`.`id` < 10)"
  15.     }
  16.    ] /* steps */
  17.   } /* join_preparation */
  18.  },
  19.  {
  20.    "join_optimization": {  //进行优化
  21.     "select#": 1,
  22.     "steps": [
  23.     {
  24.       "condition_processing": {  //条件处理
  25.        "condition": "WHERE",
  26.        "original_condition": "(`student`.`id` < 10)",
  27.        "steps": [
  28.        {
  29.          "transformation": "equality_propagation",
  30.          "resulting_condition": "(`student`.`id` < 10)"
  31.        },
  32.        {
  33.          "transformation": "constant_propagation",
  34.          "resulting_condition": "(`student`.`id` < 10)"
  35.        },
  36.        {
  37.          "transformation": "trivial_condition_removal",
  38.          "resulting_condition": "(`student`.`id` < 10)"
  39.        }
  40. ] /* steps */
  41.      } /* condition_processing */
  42.     },
  43.     {
  44.       "substitute_generated_columns": {  //替换生成的列
  45.      } /* substitute_generated_columns */
  46.     },
  47.     {
  48.       "table_dependencies": [   //表的依赖关系
  49.       {
  50.         "table": "`student`",
  51.         "row_may_be_null": false,
  52.         "map_bit": 0,
  53.         "depends_on_map_bits": [
  54.        ] /* depends_on_map_bits */
  55.       }
  56.      ] /* table_dependencies */
  57.     },
  58.     {
  59.       "ref_optimizer_key_uses": [   //使用键
  60.      ] /* ref_optimizer_key_uses */
  61.     },
  62.     {
  63.       "rows_estimation": [   //行判断
  64.       {
  65.         "table": "`student`",
  66.         "range_analysis": {
  67.          "table_scan": {
  68.           "rows": 3973767,
  69.           "cost": 408558
  70.         } /* table_scan */,   //扫描表
  71.          "potential_range_indexes": [   //潜在的范围索引
  72.          {
  73.            "index": "PRIMARY",
  74.            "usable": true,
  75.            "key_parts": [
  76.             "id"
  77.           ] /* key_parts */
  78.          }
  79.         ] /* potential_range_indexes */,
  80.          "setup_range_conditions": [   //设置范围条件
  81.         ] /* setup_range_conditions */,
  82.          "group_index_range": {
  83.           "chosen": false,
  84.           "cause": "not_group_by_or_distinct"
  85.         } /* group_index_range */,
  86.          "skip_scan_range": {
  87.           "potential_skip_scan_indexes": [
  88.           {
  89.             "index": "PRIMARY",
  90.             "usable": false,
  91.             "cause": "query_references_nonkey_column"
  92.           }
  93.          ] /* potential_skip_scan_indexes */
  94.         } /* skip_scan_range */,
  95.          "analyzing_range_alternatives": {  //分析范围选项
  96.           "range_scan_alternatives": [
  97.           {
  98. "index": "PRIMARY",
  99.             "ranges": [
  100.              "id < 10"
  101.            ] /* ranges */,
  102.             "index_dives_for_eq_ranges": true,
  103.             "rowid_ordered": true,
  104.             "using_mrr": false,
  105.             "index_only": false,
  106.             "rows": 9,
  107.             "cost": 1.91986,
  108.             "chosen": true
  109.           }
  110.          ] /* range_scan_alternatives */,
  111.           "analyzing_roworder_intersect": {
  112.            "usable": false,
  113.            "cause": "too_few_roworder_scans"
  114.          } /* analyzing_roworder_intersect */
  115.         } /* analyzing_range_alternatives */,
  116.          "chosen_range_access_summary": {   //选择范围访问摘要
  117.           "range_access_plan": {
  118.            "type": "range_scan",
  119.            "index": "PRIMARY",
  120.            "rows": 9,
  121.            "ranges": [
  122.             "id < 10"
  123.           ] /* ranges */
  124.          } /* range_access_plan */,
  125.           "rows_for_plan": 9,
  126.           "cost_for_plan": 1.91986,
  127.           "chosen": true
  128.         } /* chosen_range_access_summary */
  129.        } /* range_analysis */
  130.       }
  131.      ] /* rows_estimation */
  132.     },
  133.     {
  134.       "considered_execution_plans": [  //考虑执行计划
  135.       {
  136.         "plan_prefix": [
  137.        ] /* plan_prefix */,
  138.         "table": "`student`",
  139.         "best_access_path": {  //最佳访问路径
  140.          "considered_access_paths": [
  141.          {
  142.            "rows_to_scan": 9,
  143.            "access_type": "range",
  144.            "range_details": {
  145.             "used_index": "PRIMARY"
  146.           } /* range_details */,
  147.            "resulting_rows": 9,
  148.            "cost": 2.81986,
  149.            "chosen": true
  150.          }
  151.         ] /* considered_access_paths */
  152.        } /* best_access_path */,
  153.         "condition_filtering_pct": 100,  //行过滤百分比
  154.         "rows_for_plan": 9,
  155.         "cost_for_plan": 2.81986,
  156.         "chosen": true
  157.       }
  158.      ] /* considered_execution_plans */
  159.     },
  160.     {
  161.       "attaching_conditions_to_tables": {  //将条件附加到表上
  162.        "original_condition": "(`student`.`id` < 10)",
  163.        "attached_conditions_computation": [
  164.       ] /* attached_conditions_computation */,
  165.        "attached_conditions_summary": [  //附加条件概要
  166.        {
  167.          "table": "`student`",
  168.          "attached": "(`student`.`id` < 10)"
  169.        }
  170.       ] /* attached_conditions_summary */
  171.      } /* attaching_conditions_to_tables */
  172.     },
  173.     {
  174.       "finalizing_table_conditions": [
  175.       {
  176.         "table": "`student`",
  177.         "original_table_condition": "(`student`.`id` < 10)",
  178.         "final_table_condition  ": "(`student`.`id` < 10)"
  179.       }
  180.      ] /* finalizing_table_conditions */
  181.     },
  182.     {
  183.       "refine_plan": [  //精简计划
  184.       {
  185.         "table": "`student`"
  186.       }
  187.      ] /* refine_plan */
  188.     }
  189.    ] /* steps */
  190.   } /* join_optimization */
  191.  },
  192.  {
  193.    "join_execution": {   //执行
  194.     "select#": 1,
  195.     "steps": [
  196.    ] /* steps */
  197.   } /* join_execution */
  198.  }
  199. ] /* steps */
  200. }
  201. //第3部分：跟踪信息过长时，被截断的跟踪信息的字节数。
  202. MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0  //丢失的超出最大容量的字节
  203. //第4部分：执行跟踪语句的用户是否有查看对象的权限。当不具有权限时，该列信息为1且TRACE字段为空，一般在
  204. 调用带有SQL SECURITY DEFINER的视图或者是存储过程的情况下，会出现此问题。
  205. INSUFFICIENT_PRIVILEGES: 0  //缺失权限
  206. 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视图使用场景

索引情况

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

表相关

  1. # 1. 查询表的访问量 
  2. 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; 
  4. # 2. 查询占用bufferpool较多的表 
  5. select object_schema,object_name,allocated,data from sys.innodb_buffer_stats_by_table order by allocated limit 10; 
  7. # 3. 查看表的全表扫描情况 
  8. select * from sys.statements_with_full_table_scans where db='dbname';

语句相关

  1. #1. 监控SQL执行的频率 
  2. select db,exec_count,query from sys.statement_analysis order by exec_count desc; 
  4. #2. 监控使用了排序的SQL select db,exec_count,first_seen,last_seen,query from sys.statements_with_sorting limit 1; 
  6. #3. 监控使用了临时表或者磁盘临时表的SQL 
  7. 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. #1. 查看消耗磁盘IO的文件 
  2. 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. #1. 行锁阻塞情况 
  2. select * from sys.innodb_lock_waits;

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

10. 小结

查询是数据库中最频繁的操作，提高查询速度可以有效得提高MySQL 数据库的性能。通过对查询的语句的分析可以了解查询语句的执行情况，找出查询语句执行的瓶颈，从而优化查询语句。