MySQL高级篇知识点——性能分析工具的使用

小鱼儿 2023-10-06 23:41 2阅读 0赞

#### 目录 ####

*  1.数据库服务器的优化步骤
 *  2.查看系统性能参数
 *  3.统计SQL的查询成本：last\_query\_cost
 *  4.定位执行慢的 SQL：慢查询日志
 *   *  4.1.开启慢查询日志参数
     *  4.2.查看慢查询数目
     *  4.3.创建表以及模拟数据
     *   *  4.3.1.建表
         *  4.3.2.创建相关函数
         *  4.3.3.创建并调用存储过程
     *  4.4.测试及分析
     *   *  4.4.1.测试
         *  4.4.2.分析
     *  4.5.慢查询日志分析工具：mysqldumpslow
     *  4.6.关闭慢查询日志
     *  4.7.删除慢查询日志
 *  5.查看 SQL 执行成本：SHOW PROFILE
 *  6.分析查询语句：EXPLAIN
 *   *  6.1.概述
     *   *  6.1.1.能做什么？
         *  6.1.2.官网介绍
     *  6.2.基本语法
     *  6.3.数据准备
     *   *  6.3.1.建表
         *  6.3.2.创建相关函数
         *  6.3.3.创建存储过程
         *  6.3.4.调用存储过程
     *  6.4.EXPLAIN 各列作用
     *   *  6.4.1.table
         *  6.4.2.id
         *  6.4.3.select\_type
         *  6.4.4.partition（可略）
         *  6.4.5.type（重要）
         *  6.4.6.possible\_keys 和 key
         *  6.4.7.key\_len（重要）
         *  6.4.8.ref
         *  6.4.9.rows（重要）
         *  6.4.10.filtered
         *  6.4.11.Extra
         *  6.4.12.小结
 *  7.EXPLAIN 的进一步使用
 *   *  7.1.EXPLAIN 四种输出格式
     *   *  7.1.1.传统格式
         *  7.1.2.JSON 格式
         *  7.1.3.TREE 格式
         *  7.1.4.可视化输出
     *  7.2.SHOW WARNINGS 使用
 *  8.分析优化器执行计划：trace
 *  9.MySQL 监控分析视图——sys schema
 *   *  9.1.Sys schema视图摘要
     *  9.2.Sys schema视图使用场景
     *   *  9.2.1.索引情况
         *  9.2.2.表相关
         *  9.2.3.语句相关
         *  9.2.4.I/O 相关
         *  9.2.5.Innodb 相关

> 本文笔记整理来自尚硅谷视频[https://www.bilibili.com/video/BV1iq4y1u7vj?p=134][https_www.bilibili.com_video_BV1iq4y1u7vj_p_134]，相关资料可在视频评论区进行获取。

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

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

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

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

（2）详细解释以下上面的图：  
① 首先在 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。

**（3）小结**  
![在这里插入图片描述][1aaef6a9d09148748f61563daff44d18.png]

## 2.查看系统性能参数 ##

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

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

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

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Connections</td> 
   <td>连接 MySQL 服务器的次数</td> 
  </tr> 
  <tr> 
   <td>Uptime</td> 
   <td>MySQL 服务器的上线时间</td> 
  </tr> 
  <tr> 
   <td>Slow_queries</td> 
   <td>慢查询的次数</td> 
  </tr> 
  <tr> 
   <td>Innodb_rows_read</td> 
   <td>Select 查询返回的行数</td> 
  </tr> 
  <tr> 
   <td>Innodb_rows_inserted</td> 
   <td>执行 INSERT 操作插入的行数</td> 
  </tr> 
  <tr> 
   <td>Innodb_rows_updated</td> 
   <td>执行 UPDATE 操作更新的行数</td> 
  </tr> 
  <tr> 
   <td>Innodb_rows_deleted</td> 
   <td>执行 DELETE 操作删除的行数</td> 
  </tr> 
  <tr> 
   <td>Com_select</td> 
   <td>查询操作的次数</td> 
  </tr> 
  <tr> 
   <td>Com_insert</td> 
   <td>插入操作的次数。对于批量插入的 INSERT 操作，只累加一次</td> 
  </tr> 
  <tr> 
   <td>Com_update</td> 
   <td>更新操作的次数</td> 
  </tr> 
  <tr> 
   <td>Com_delete</td> 
   <td>删除操作的次数</td> 
  </tr> 
 </tbody> 
</table>

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

SHOW STATUS LIKE 'Connections';

## 3.统计SQL的查询成本：last\_query\_cost ##

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

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

（3）我们依然使用[索引的创建与设计原则][Link 1]中的 student\_info 表为例：

# 创建学生表和课程表
    CREATE TABLE `student_info` (
     `id` INT(11) AUTO_INCREMENT,
     `student_id` INT NOT NULL ,
     `name` VARCHAR(20) DEFAULT NULL,
     `course_id` INT NOT NULL ,
     `class_id` INT(11) DEFAULT NULL,
     `create_time` DATETIME DEFAULT NULL,
     PRIMARY KEY (`id`)
    ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

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

SELECT * FROM student_info WHERE id = 900001;

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

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

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

SELECT * FROM student_info WHERE id BETWEEN 900001 AND 900100;

运行结果（100 条记录，运行时间为 0.006s ）：

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

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

（4）使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。

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

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

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

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

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

### 4.1.开启慢查询日志参数 ###

（1）查看慢查询开启情况，默认是不开启的。

SHOW VARIABLES LIKE '%slow_query_log%';

![在这里插入图片描述][3281481abb3a48a5adb8a6062ec1ced1.png]  
（2）开启慢查询之后，再次查看。

# slow_query_log 是全部变量
    SET GLOBAL slow_query_log='ON';
    
    SHOW VARIABLES LIKE '%slow_query_log%';

![在这里插入图片描述][00bc4eedaaa0421091ac1474bc18b535.png]  
你能看到这时慢查询分析已经开启，同时文件保存在 slow\_query\_log\_file 文件中。

（3）查看并修改 long\_query\_time 阈值。

# 默认是 10s
    show variables like '%long_query_time%';
    
    # 修改为 1s
    # 测试发现：设置 global 的方式对当前 session 的 long_query_time 失效，对新连接的客户端有效。所以可以一并 执行下述语句
    set global long_query_time = 1;
    SET long_query_time = 1;

![在这里插入图片描述][a27367de6e484c12ae43927937f606c7.png]  
![在这里插入图片描述][c4f31be0084d4ccbb38f8db0d0e317e5.png]

（4）上面的方法只是临时修改，一但 MySQL 重启，上述设置又会恢复到默认值，永久修改的方法如下：  
① 如果是在 windows下：在配置文件 my.ini \[mysqld\] 中修改或加上：  
② 如果是在 linux下：则在配置文件 /etc/my.cnf \[mysqld\] 中修改或加上：

slow_query_log=ON
    long_query_time=1
    slow_query_log_file='具体文件路径名'
    log_output=FILE

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

### 4.2.查看慢查询数目 ###

查询当前系统中有多少条慢查询记录，如果是刚开启慢查询且还没有执行时间超过 long\_query\_time 的语句，那么慢查询数目肯定为 0

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

### 4.3.创建表以及模拟数据 ###

#### 4.3.1.建表 ####

USE atguigudb1;
    
    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;

#### 4.3.2.创建相关函数 ####

创建的[MySQL高级篇知识点——索引的创建与设计原则][Link 1]这篇文章中的 3.1 节一样。  
**（1）产生随机字符串函数**

DELIMITER //
    CREATE FUNCTION rand_string(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）产生随机数值函数**

DELIMITER //
    CREATE FUNCTION rand_num (from_num INT ,to_num INT) RETURNS INT(11)
    BEGIN   
    DECLARE i INT DEFAULT 0;  
    SET i = FLOOR(from_num +RAND()*(to_num - from_num+1))   ;
    RETURN i;  
    END //
    DELIMITER ;

#### 4.3.3.创建并调用存储过程 ####

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 ;
    
    # 调用刚刚写好的存储过程, 4000000 条记录，从 100001 号开始（该过程所需的时间可能比较长）
    CALL insert_stu1(100001, 4000000);

![在这里插入图片描述][227096f2a6fb42459c73ff8f72e50dee.png]

### 4.4.测试及分析 ###

#### 4.4.1.测试 ####

# 花费 1.485s
    SELECT * FROM student WHERE stuno = 3455655;
    # 花费 1.461s
    SELECT * FROM student WHERE NAME = 'McaXLK';

![在这里插入图片描述][4b675b1c00f44fab8cbd16f7c8d2b87d.png]

#### 4.4.2.分析 ####

SHOW STATUS LIKE 'slow_queries';

![在这里插入图片描述][78e994252fc741568bbb9ddc4902679d.png]

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

![在这里插入图片描述][8801667bcb1e4f788001122c48d67a14.png]

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

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

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

# Windows 下默认是没安装 mysqldumpslow 脚本的，下图的命令是在 Linux 中执行的
    mysqldumpslow --help

![在这里插入图片描述][a9b46d22789a4c6cba4c91458c8a12ea.png]  
**（2）mysqldumpslow 命令的部分常用参数如下：**

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-a</td> 
   <td>不将数字抽象成为 N，字符串抽象成为 S</td> 
  </tr> 
  <tr> 
   <td>-s</td> 
   <td>是表示按照何种方式排序</td> 
  </tr> 
  <tr> 
   <td>-t</td> 
   <td>即为返回前面多少条的数据</td> 
  </tr> 
  <tr> 
   <td>-g</td> 
   <td>后边搭配一个正则匹配模式，大小写不敏感的</td> 
  </tr> 
 </tbody> 
</table>

\-s 下的排序方式参数如下：

<table> 
 <thead> 
  <tr> 
   <th>c</th> 
   <th>访问次数</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>l</td> 
   <td>锁定时间</td> 
  </tr> 
  <tr> 
   <td>r</td> 
   <td>返回记录</td> 
  </tr> 
  <tr> 
   <td>t</td> 
   <td>查询时间</td> 
  </tr> 
  <tr> 
   <td>al</td> 
   <td>平均锁定时间</td> 
  </tr> 
  <tr> 
   <td>ar</td> 
   <td>平均返回记录数</td> 
  </tr> 
  <tr> 
   <td>at</td> 
   <td>平均查询时间 （默认方式）</td> 
  </tr> 
  <tr> 
   <td>ac</td> 
   <td>平均查询次数</td> 
  </tr> 
 </tbody> 
</table>

（3）举例（下面的语句都是在 Linux 环境下执行的）  
① 我们想要按照查询时间排序，查看前五条 SQL 语句，这样写即可：

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

![在这里插入图片描述][82fc798ba1ea494f9840f386033a6af9.png]

**② 常用命令**

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

### 4.6.关闭慢查询日志 ###

MySQL服务器停止慢查询日志功能有两种方法：  
**（1）永久性方式**

[mysqld] 
    slow_query_log=OFF
    
    # 或者把 slow_query_log 一项注释掉或删除
    [mysqld] 
    # slow_query_log=OFF

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

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

**（2）临时性方式**  
使用 SET 语句来设置。  
① 停止 MySQL 慢查询日志功能，具体 SQL 语句如下：

SET GLOBAL slow_query_log=off;

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

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

### 4.7.删除慢查询日志 ###

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

SHOW VARIABLES LIKE '%slow_query_log%';

从执行结果可以看出，慢查询日志的目录默认为 MySQL 的数据目录，在该目录下手动删除慢查询日志文件即可。

（2）使用命令 mysqladmin flush-logs 来重新生成查询日志文件，执行完毕会在数据目录下重新生成慢查询日志文件。

mysqladmin -uroot -p flush-logs slow

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

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

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

（2）我们可以在会话级别开启这个功能：

mysql >show variables like 'profiling';

![在这里插入图片描述][284b5951fba34c468e96315661b21ec5.png]  
通过设置 profiling='ON’ 来开启 show profile：

set profiling = 'ON';

![在这里插入图片描述][d7df1a0707a842709b4aa85da05bcee5.png]

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

mysql > show profiles;

![在这里插入图片描述][060c5cd1564744d68ce36b008951bbf8.png]  
你能看到当前会话一共有 2 个查询。如果我们想要查看最近一次查询的开销，可以使用：

mysql > show profile;

![在这里插入图片描述][5dde122fd1de4aa89bd182ece7519485.png]

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

![在这里插入图片描述][fbf6f294acd3451eafab33570151ca1f.png]

**（4）show profile 的常用查询参数：**

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>ALL</td> 
   <td>显示所有的开销信息</td> 
  </tr> 
  <tr> 
   <td>BLOCK IO</td> 
   <td>显示块 IO 开销</td> 
  </tr> 
  <tr> 
   <td>CONTEXT SWITCHES</td> 
   <td>上下文切换开销</td> 
  </tr> 
  <tr> 
   <td>CPU</td> 
   <td>显示 CPU 开销信息</td> 
  </tr> 
  <tr> 
   <td>IPC</td> 
   <td>显示发送和接收开销信息</td> 
  </tr> 
  <tr> 
   <td>MEMORY</td> 
   <td>显示内存开销信息</td> 
  </tr> 
  <tr> 
   <td>PAGE FAULTS</td> 
   <td>显示页面错误开销信息</td> 
  </tr> 
  <tr> 
   <td>SOURCE</td> 
   <td>显示和 Source_function，Source_file， Source_line 相关的开销信息</td> 
  </tr> 
  <tr> 
   <td>SWAPS</td> 
   <td>显示交换次数开销信息</td> 
  </tr> 
 </tbody> 
</table>

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

<table> 
 <thead> 
  <tr> 
   <th>converting HEAP to MyISAM</th> 
   <th>查询结果太大，内存不够，数据往磁盘上搬了</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Creating tmp table</td> 
   <td>创建临时表。先拷贝数据到临时表，用完后再删除临时表</td> 
  </tr> 
  <tr> 
   <td>Copying to tmp table on disk</td> 
   <td>把内存中临时表复制到磁盘上，需要警惕！</td> 
  </tr> 
  <tr> 
   <td>lock</td> 
   <td>加锁</td> 
  </tr> 
 </tbody> 
</table>

如果在 show profile 诊断结果中出现了以上 4 条结果中的任何一条，则 SQL 语句需要优化。

> 注意：不过 SHOW PROFILE 命令将被弃用，我们可以从 information\_schema 中的 profiling 数据表进行查看。

## 6.分析查询语句：EXPLAIN ##

### 6.1.概述 ###

（1）定位了查询慢的 SQL 之后，我们就可以使用 EXPLAIN 或 DESCRIBE 工具做针对性的分析查询语句。DESCRIBE 语句的使用方法与 EXPLAIN 语句是一样的，并且分析结果也是一样的。

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

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

#### 6.1.1.能做什么？ ####

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

#### 6.1.2.官网介绍 ####

（1）MySQL5.7：[https://dev.mysql.com/doc/refman/5.7/en/explain-output.html ][https_dev.mysql.com_doc_refman_5.7_en_explain-output.html]  
（2）MySQL8.0：[https://dev.mysql.com/doc/refman/8.0/en/explain-output.html][https_dev.mysql.com_doc_refman_8.0_en_explain-output.html]  
（3）版本情况：  
① MySQL 5.6.3 以前只能 EXPLAIN SELECT；MYSQL 5.6.3 以后就可以 EXPLAIN SELECT，UPDATE，DELETE。  
② 在 MySQL 5.7 以前的版本中，想要显示 partitions 需要使用 explain partitions 命令；想要显示 filtered 需要使用 explain extended 命令。在 MySQL 5.7 版本后，默认 explain 直接显示 partitions和 filtered 中的信息。

### 6.2.基本语法 ###

（1）**EXPLAIN** 或 **DESCRIBE** 语句的语法形式如下：

EXPLAIN SELECT select_options 
    # 或者
    DESCRIBE SELECT select_options

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

mysql> EXPLAIN SELECT 1;

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

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

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

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

### 6.3.数据准备 ###

#### 6.3.1.建表 ####

USE atguigudb1;
    
    CREATE TABLE s1 ( 
    id INT AUTO_INCREMENT, 
    key1 VARCHAR(100), 
    key2 INT, 
    key3 VARCHAR(100), 
    key_part1 VARCHAR(100), 
    key_part2 VARCHAR(100), 
    key_part3 VARCHAR(100), 
    common_field VARCHAR(100), 
    PRIMARY KEY (id), 
    INDEX idx_key1 (key1), 
    UNIQUE INDEX idx_key2 (key2), 
    INDEX idx_key3 (key3), 
    INDEX idx_key_part(key_part1, key_part2, key_part3) 
    ) ENGINE=INNODB CHARSET=utf8;
    
    CREATE TABLE s2 ( 
    id INT AUTO_INCREMENT, 
    key1 VARCHAR(100), 
    key2 INT, 
    key3 VARCHAR(100), 
    key_part1 VARCHAR(100), 
    key_part2 VARCHAR(100), 
    key_part3 VARCHAR(100), 
    common_field VARCHAR(100), 
    PRIMARY KEY (id), 
    INDEX idx_key1 (key1), 
    UNIQUE INDEX idx_key2 (key2),
    INDEX idx_key3 (key3), 
    INDEX idx_key_part(key_part1, key_part2, key_part3) 
    ) ENGINE=INNODB CHARSET=utf8;

#### 6.3.2.创建相关函数 ####

DELIMITER // 
    CREATE FUNCTION rand_string1(n INT) 
        RETURNS VARCHAR(255) #该函数会返回一个字符串 
    BEGIN
        DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ'; 
        DECLARE return_str VARCHAR(255) DEFAULT ''; 
        DECLARE i INT DEFAULT 0; 
        WHILE i < n DO 
            SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1)); 
            SET i = i + 1; 
        END WHILE; 
        RETURN return_str; 
        END // 
    DELIMITER ;

在创建函数时，如果报错，需开启如下命令：

# 允许创建函数设置
    set global log_bin_trust_function_creators=1;  # 不加 global 只是当前窗口有效。

#### 6.3.3.创建存储过程 ####

**（1）创建往 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 ;

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

DELIMITER // 
    	CREATE PROCEDURE insert_s2 (IN min_num INT (10),IN max_num INT (10)) 
    BEGIN
    	DECLARE i INT DEFAULT 0; 
    	SET autocommit = 0; 
    	REPEAT 
    	SET i = i + 1; 
    	INSERT INTO s2 VALUES( 
    		(min_num + i), 
    		rand_string1(6), 
    		(min_num + 30 * i + 5), 
    		rand_string1(6), 
    		rand_string1(10), 
    		rand_string1(5), 
    		rand_string1(10), 
    		rand_string1(10)); 
    	UNTIL i = max_num 
    	END REPEAT; 
    	COMMIT; 
    END // 
    DELIMITER ;

#### 6.3.4.调用存储过程 ####

# s1 表数据的添加：加入 1 万条记录：
    CALL insert_s1(10001, 10000);
    
    # s2 表数据的添加：加入 1 万条记录：
    CALL insert_s2(10001, 10000);

### 6.4.EXPLAIN 各列作用 ###

#### 6.4.1.table ####

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

# 查询的每一行记录都对应着一个单表
    EXPLAIN SELECT * FROM s1;
    
    # s1:驱动表  s2:被驱动表
    EXPLAIN SELECT * FROM s1 INNER JOIN s2;

![在这里插入图片描述][55cfee86f1364e89b811a0972c443364.png]  
![在这里插入图片描述][3507d0d64bdf4f34aacf7f7f4de77e04.png]

#### 6.4.2.id ####

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

SELECT * FROM s1 WHERE key1 = 'a';

![在这里插入图片描述][82804bda7dc447c5bda37f9001da58f4.png]  
稍微复杂一点的连接查询中也只有一个 SELECT 关键字，比如：

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

![在这里插入图片描述][b1e2a3bb59174202b80051bfa8b58e11.png]  
（2）下面的 SQL 语句中有 2 个 SELECT 关键字。

EXPLAIN SELECT * FROM s1 
    WHERE key1 IN (SELECT key3 FROM s2);

![在这里插入图片描述][3ee98215513949179549764453e79eb7.png]

**（3）特殊情况（不同版本的 MySQL 执行的情况可能有一点差别）**  
① 查询优化器可能**对涉及子查询的查询语句进行重写**，转变为多表查询的操作。

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

② Union 去重

EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;

![在这里插入图片描述][cc7ff053fe294ea2821974db7a282511.png]

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

#### 6.4.3.select\_type ####

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

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

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SIMPLE</td> 
   <td>Simple SELECT (not using UNION or subqueries)</td> 
  </tr> 
  <tr> 
   <td>PRIMARY</td> 
   <td>Outermost SELECT</td> 
  </tr> 
  <tr> 
   <td>UNION</td> 
   <td>Second or later SELECT statement in a UNION</td> 
  </tr> 
  <tr> 
   <td>UNION RESULT</td> 
   <td>Result of a UNION</td> 
  </tr> 
  <tr> 
   <td>SUBQUERY</td> 
   <td>First SELECT in subquery</td> 
  </tr> 
  <tr> 
   <td>DEPENDENT SUBQUERY</td> 
   <td>First SELECT in subquery, dependent on outer query</td> 
  </tr> 
  <tr> 
   <td>DEPENDENT UNION</td> 
   <td>Second or later SELECT statement in a UNION, dependent on outer query</td> 
  </tr> 
  <tr> 
   <td>DERIVED</td> 
   <td>Derived table</td> 
  </tr> 
  <tr> 
   <td>MATERIALIZED</td> 
   <td>Materialized subquery</td> 
  </tr> 
  <tr> 
   <td>UNCACHEABLE SUBQUERY</td> 
   <td>A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query</td> 
  </tr> 
  <tr> 
   <td>UNCACHEABLE UNION</td> 
   <td>The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)</td> 
  </tr> 
 </tbody> 
</table>

（3）举例  
① SIMPLE：查询语句中不包含 `UNION` 或者子查询的查询都算作是 `SIMPLE` 类型。

EXPLAIN SELECT * FROM s1;
    
    # 连接查询也算是`SIMPLE`类型
    EXPLAIN SELECT * FROM s1 INNER JOIN s2;

![在这里插入图片描述][ab06528cf17c40ceb51f523f88fb6817.png]  
![在这里插入图片描述][4143f3488ffe4ad2a9d66d1b2ef96b02.png]

② PRIMARY 与 UNION：对于包含 `UNION` 或者 `UNION ALL` 或者子查询的大查询来说，它是由几个小查询组成的，其中最左边的那个查询的 `select_type` 值就是 `PRIMARY`，除了最左边的那个小查询以外，其余的小查询的`select_type`值就是`UNION`。此外，`MySQL` 选择使用临时表来完成 `UNION` 查询的去重工作，针对该临时表的查询的 `select_type` 就是 `UNION RESULT`。

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

![在这里插入图片描述][cbfb899c90dc456b950ce9e7f1ede3a9.png]  
![在这里插入图片描述][42204d4eb9f946d5a27e2a562bab0983.png]

③ SUBQUERY ：如果包含子查询的查询语句不能够转为对应的 `semi-join`（多表连接）的形式，并且该子查询是不相关子查询，那么该子查询的第一个 `SELECT` 关键字代表的那个查询的 `select_type` 就是 `SUBQUERY`。

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

![在这里插入图片描述][83d5aa6d5842422482ec9916813addac.png]

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

# 注意：select_type为`DEPENDENT SUBQUERY`的查询可能会被执行多次。
    EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2 WHERE s1.key2 = s2.key2) OR key3 = 'a';

![在这里插入图片描述][cc864d47951b45ceba52e0576b8dd3a5.png]

⑤ DEPENDENT SUBQUERY：在包含 `UNION` 或者 `UNION ALL` 的大查询中，如果各个小查询都依赖于外层查询的话，那除了最左边的那个小查询之外，其余的小查询的 `select_type` 的值就是 `DEPENDENT UNION`。

# 优化器有时会将 IN 替换为 EXISTS
    EXPLAIN SELECT * FROM s1 
    WHERE key1 IN (SELECT key1 FROM s2 WHERE key1 = 'a' UNION SELECT key1 FROM s1 WHERE key1 = 'b');

![在这里插入图片描述][3e99c0d632ce41038cbc9cec57e0ca33.png]

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

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

![在这里插入图片描述][bc8f8d3848ca489e981ab793d9fde371.png]

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

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

![在这里插入图片描述][fd4957cbc6e145ab922090427eaa9fdd.png]

#### 6.4.4.partition（可略） ####

（1）代表分区表中的命中情况，非分区表，该项为 NULL。一般情况下我们的查询语句的执行计划的 partitions 列的值都是 NULL。  
（2）官方文档：[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]  
（3）如果想详细了解，可以如下方式测试。创建分区表：

# 创建分区表，
    # 按照 id 分区，id < 100 为 p0 分区，其它为 p1 分区
    CREATE TABLE user_partitions (
    id INT auto_increment,
    NAME VARCHAR(12), 
    PRIMARY KEY (id)
    )
    PARTITION BY RANGE(id)(
    	PARTITION pe VALUES less than(100),
    	PARTITION p1 VALUES less than MAXVALUE
    );
    
    DESC SELECT * FROM user_partitions WHERE id > 208;

查询 id 大于 200（200 > 100，p1 分区）的记录，查看执行计划，partitions 是 p1，符合我们的分区规则。  
![在这里插入图片描述][b743ff98781641ce9e349f5d06716016.png]

#### 6.4.5.type（重要） ####

（1）执行计划的一条记录就代表着 MySQL 对某个表的**执行查询时的访问方法**，又称“访问类型”，其中的 type 列就表明了这个访问方法是什么，是较为重要的一个指标。比如，看到 type 列的值是 ref，表明 MySQL 即将使用 ref 访问方法来执行对 s1 表的查询。

（2）完整的访问方法如下：system、const、eq\_ref、ref、fulltext、ref\_or\_null、index\_merge、unique\_subquery、index\_subquery、range、index、ALL（访问类型越往后，说明效果越差）。

① system：当表中 `只有一条记录` 并且该表使用的存储引擎的统计数据是精确的，比如 MyISAM、Memory 等，那么对该表的访问方法就是 `system`。

CREATE TABLE t(i INT) ENGINE=MYISAM;
     
     INSERT INTO t VALUES(1);
     
     EXPLAIN SELECT * FROM t;
    # 如果再插入一条记录，那么 type 的结果为 ALL

![在这里插入图片描述][5930d116cf504b78bdae049ced26af8a.png]

# 换成 InnoDB
     CREATE TABLE tt(i INT) ENGINE=INNODB;
     
     INSERT INTO tt VALUES(1);
     
     EXPLAIN SELECT * FROM tt;

![在这里插入图片描述][606d39f7ad6545e6b2a6c249f0a1e07e.png]

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

EXPLAIN SELECT * FROM s1 WHERE id = 10005;

![在这里插入图片描述][76939beefe7e412ea040d348ac096854.png]

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

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

![在这里插入图片描述][fc5c63802d35497bb0e36d232465bc2e.png]

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

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

![在这里插入图片描述][f01af07e5b9840fea8c7c3d0d3ded8b6.png]

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

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

![在这里插入图片描述][1c7b8c98859d4995854864720ab7978b.png]

⑥ index\_merge：单表访问方法时在某些场景下可以使用 `Intersection`、`Union`、`Sort-Union` 这三种索引合并的方式来执行查询

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

![在这里插入图片描述][4fb73f3afc814f1ca1bfe1da39ce799f.png]

⑦ unique\_subquery：`unique_subquery` 是针对在一些包含 `IN` 子查询的查询语句中，如果查询优化器决定将 `IN`子查询转换为 `EXISTS` 子查询，而且子查询可以使用到主键进行等值匹配的话，那么该子查询执行计划的 `type` 列的值就是`unique_subquery`。

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

![在这里插入图片描述][b88d2b68f09b4eb9b643080e15bc0c38.png]

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

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

![在这里插入图片描述][ddf91f1aeb954b5f8c5cc96de54eac84.png]

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

# 要查询的字段和 WHERE 中的字段恰好都是联合索引 idx_key_part 中的一部分，所以此时干脆就使用了索引 idx_key_part 
    EXPLAIN SELECT key_part2 FROM s1 WHERE key_part3 = 'a';

![在这里插入图片描述][79ceb542714e4da5b17460aead962eb5.png]

⑩ ALL ：全表扫描。

EXPLAIN SELECT * FROM s1;

![在这里插入图片描述][168a186ca0f54fd5b07b8727088632bb.png]  
**（3）小结**  
① 一般来说，这些访问方法中除了 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.4.6.possible\_keys 和 key ####

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

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

![在这里插入图片描述][14397341c22f47e0af65f271c508be34.png]

（2）上述执行计划的 possible\_keys 列的值是 idx\_key1, idx\_key3，表示该查询可能使用到 idx\_key1, idx\_key3 这两个索引，然后 key 列的值是 idx\_key3，表示经过查询优化器计算使用不同索引的成本后，最后决定使用 idx\_key3 来执行查询比较划算。

#### 6.4.7.key\_len（重要） ####

（1）key\_len 指实际使用到的索引长度（单位是字节数），帮忙检查 `是否充分地利用上了索引`，对于同一个索引来说，其`值越大越好`。它主要针对于联合索引，有一定的参考意义。

（2）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)

（3）举例

EXPLAIN SELECT * FROM s1 WHERE id = 10005;

![在这里插入图片描述][e52c8e5ae17440e488f4357de0a7bbe9.png]

EXPLAIN SELECT * FROM s1 WHERE key2 = 10126;

![在这里插入图片描述][98999d32754749148ac505360db9fde1.png]

EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a';
    
    EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b';
    
    EXPLAIN SELECT * FROM s1 WHERE key_part1 = 'a' AND key_part2 = 'b' AND key_part3 = 'c';

![在这里插入图片描述][2e2a9360c8474a068f8741709a57a1f4.png]  
![在这里插入图片描述][f6d22a03e5b2447bbcec04f4f4721451.png]  
![在这里插入图片描述][07a5a25cc0164e4c86fc7e44f5ae7036.png]

#### 6.4.8.ref ####

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

# 比如只是一个常数或者是某个列。
    EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';
     
    EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.id = s2.id;
     
    EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s2.key1 = UPPER(s1.key1);

![在这里插入图片描述][95964c20e664460c9c7d81976a1dd55b.png]  
![在这里插入图片描述][865a1e34d9a44fe2bee283d993c852b8.png]  
![在这里插入图片描述][6bd5a00824cb4fa1a3b5a69759df8a00.png]

#### 6.4.9.rows（重要） ####

rows：预估的需要读取的记录条数，`值越小越好`。

EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';

![在这里插入图片描述][9cec1319af304f9bb8cea638bee1f619.png]

#### 6.4.10.filtered ####

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

# 如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。
     EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';

![在这里插入图片描述][d939577155e142b6bc37ba393f88cda8.png]

# 对于单表查询来说，这个filtered列的值没什么意义，我们更关注在连接查询中驱动表对应的执行计划记录的 filtered 值，
     # 它决定了被驱动表要执行的次数(即：rows * filtered)
     EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';

![在这里插入图片描述][f906e109838142ddad64bcda860f6220.png]

#### 6.4.11.Extra ####

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

（1）No tables used：当查询语句的没有 `FROM` 子句时将会提示该额外信息。

EXPLAIN SELECT 1;

![在这里插入图片描述][14cf3c818f354081b5ed8000a9e00383.png]

（2）Impossible WHERE：查询语句的 `WHERE` 子句永远为 `FALSE` 时将会提示该额外信息。

EXPLAIN SELECT * FROM s1 WHERE 1 != 1;

![在这里插入图片描述][fd05a9f8594d4b55b169af24abbaea7b.png]

（3）Using where：当我们使用全表扫描来执行对某个表的查询，并且该语句的 `WHERE` 子句中有针对该表的搜索条件时，在`Extra`列中会提示该额外信息。此外，当使用索引访问来执行对某个表的查询，并且该语句的 `WHERE` 子句中有除了该索引包含的列之外的其他搜索条件时，在 `Extra` 列中也会提示上述额外信息。

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

![在这里插入图片描述][6f4839b911114f4c87a123468e201677.png]  
![在这里插入图片描述][2f779b703cc8469783a2e2d5a1a3d78f.png]

（4）No matching min/max row：当查询列表处有 `MIN` 或者 `MAX` 聚合函数，但是并没有符合 `WHERE` 子句中的搜索条件的记录时，将会提示该额外信息。

EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'abcdefg';

![在这里插入图片描述][5e6080087ba24c249986bbec0da54794.png]

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

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

![在这里插入图片描述][e45e7738398c43258579cc69656b3317.png]

（6）Using index condition：有些搜索条件中虽然出现了索引列，但却不能使用到索引。

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

![在这里插入图片描述][73d51c1459b149e7937bef9c98978037.png]

其中的 **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’ 这个条件的二级索引记录执行回表操作。

我们说回表操作其实是一个随机 I/O，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。MySQL 把它们的这个改进称之为索引条件下推 (Index Condition Pushdown)。如果在查询语句的执行过程中将要使用索引条件下推这个特性，在 Extra 列中将会显示 Using index condition。

（7）Using join buffer (Block Nested Loop)：在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫 `join buffer` 的内存块来加快查询速度，也就是我们所讲的 `基于块的嵌套循环算法`。

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

![在这里插入图片描述][1d808e5fe2b14ecb8e195f83a4a7c97e.png]

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

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

![在这里插入图片描述][3c290693f19c4d168f5ed5cfb67a7d62.png]

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

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

![在这里插入图片描述][b30a3dbee652428093647c5d8f60f033.png]

（10）Zero limit：当 `LIMIT` 子句的参数为 `0` 时，表示不打算从表中读出任何记录，将会提示该额外信息。

EXPLAIN SELECT * FROM s1 LIMIT 0;

![在这里插入图片描述][b762601541644457868aaf31a2c2330e.png]

（11）Using filesort：很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）进行排序，MySQL 把这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名：`filesort`）。如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的 `Extra` 列中显示 `Using filesort` 提示。

EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10;

![在这里插入图片描述][cef7c41f489b481aab504737f3a3ac21.png]

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

EXPLAIN SELECT DISTINCT common_field FROM s1;

![在这里插入图片描述][19f5486a9be14f919d50a9a8a3583760.png]

#### 6.4.12.小结 ####

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

## 7.EXPLAIN 的进一步使用 ##

### 7.1.EXPLAIN 四种输出格式 ###

#### 7.1.1.传统格式 ####

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

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

![在这里插入图片描述][63785595326040f0b363f83b06fcd267.png]

#### 7.1.2.JSON 格式 ####

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

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

EXPLAIN FORMAT=JSON SELECT ....

EXPLAIN 的 column 与 JSON 的对应关系（来源于 MySQL 5.7 文档）：  
![在这里插入图片描述][a96de9d1011b41f9928fd053647d3991.png]

#### 7.1.3.TREE 格式 ####

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

![在这里插入图片描述][e11bce7138b74becbe28def29b82fbdd.png]

#### 7.1.4.可视化输出 ####

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

### 7.2.SHOW WARNINGS 使用 ###

（1）在我们使用 EXPLAIN 语句查看了某个查询的执行计划后，紧接着还可以使用 SHOW WARNINGS 语句查看与这个查询的执行计划有关的一些扩展信息，比如这样：  
![在这里插入图片描述][cd7233f6ebab416e80a9a1a4f327e0fb.png]

大家可以看到 **SHOW WARNINGS** 展示出来的信息有三个字段，分别是 **Level**、**Code**、**Message**。

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

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

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

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

（2）开启后，可分析如下语句：SELECT、INSERT、REPLACE、UPDATE、DELETE、EXPLAIN、SET、DECLARE、CASE、IF、RETURN、CALL。

（3）测试：执行如下 SQL 语句

select * from student where id < 10;

最后，查询 information\_schema.optimizer\_trace 就可以知道 MySQL 是如何执行SQL的（结果太长，此处不便展示）：

select * from information_schema.optimizer_trace

## 9.MySQL 监控分析视图——sys schema ##

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

### 9.1.Sys schema视图摘要 ###

<table> 
 <thead> 
  <tr> 
   <th>主机相关</th> 
   <th>以 host_summary 开头，主要汇总了 I/O 延迟的信息</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Innodb 相关</td> 
   <td>以 Innodb 开头，汇总了 Innodb buffer 信息和事务等待 Innodb 锁的信息</td> 
  </tr> 
  <tr> 
   <td>I/O 相关</td> 
   <td>以 I/O 开头，汇总了等待 I/O、I/O 使用量情况</td> 
  </tr> 
  <tr> 
   <td>内存使用情况</td> 
   <td>以 memory 开头，从主机、线程、事件等角度展示内存的使用情况</td> 
  </tr> 
  <tr> 
   <td>连接与会话信息</td> 
   <td>processlist 和 session 相关视图，总结了会话相关信息</td> 
  </tr> 
  <tr> 
   <td>表相关</td> 
   <td>以 schema_table 开头的视图，展示了表的统计信息</td> 
  </tr> 
  <tr> 
   <td>索引信息</td> 
   <td>统计了索引的使用情况，包含冗余索引和未使用的索引情况</td> 
  </tr> 
  <tr> 
   <td>语句相关</td> 
   <td>以 statement 开头，包含执行全表扫描、使用临时表、排序等的语句信息</td> 
  </tr> 
  <tr> 
   <td>用户相关</td> 
   <td>以 user 开头的视图，统计了用户使用的文件I/O、执行语句统计信息</td> 
  </tr> 
  <tr> 
   <td>等待事件相关信息</td> 
   <td>以wait开头，展示等待事件的延迟情况</td> 
  </tr> 
 </tbody> 
</table>

### 9.2.Sys schema视图使用场景 ###

#### 9.2.1.索引情况 ####

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

#### 9.2.2.表相关 ####

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

#### 9.2.3.语句相关 ####

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

#### 9.2.4.I/O 相关 ####

# 1.查看消耗磁盘 I/O 的文件 
    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;

#### 9.2.5.Innodb 相关 ####

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

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

[https_www.bilibili.com_video_BV1iq4y1u7vj_p_134]: https://www.bilibili.com/video/BV1iq4y1u7vj?p=134
[93a453dc856c46f08212ce79e873f80d.png]: https://img-blog.csdnimg.cn/93a453dc856c46f08212ce79e873f80d.png
[1aaef6a9d09148748f61563daff44d18.png]: https://img-blog.csdnimg.cn/1aaef6a9d09148748f61563daff44d18.png
[Link 1]: https://blog.csdn.net/weixin_43004044/article/details/126419076
[3281481abb3a48a5adb8a6062ec1ced1.png]: https://img-blog.csdnimg.cn/3281481abb3a48a5adb8a6062ec1ced1.png
[00bc4eedaaa0421091ac1474bc18b535.png]: https://img-blog.csdnimg.cn/00bc4eedaaa0421091ac1474bc18b535.png
[a27367de6e484c12ae43927937f606c7.png]: https://img-blog.csdnimg.cn/a27367de6e484c12ae43927937f606c7.png
[c4f31be0084d4ccbb38f8db0d0e317e5.png]: https://img-blog.csdnimg.cn/c4f31be0084d4ccbb38f8db0d0e317e5.png
[227096f2a6fb42459c73ff8f72e50dee.png]: https://img-blog.csdnimg.cn/227096f2a6fb42459c73ff8f72e50dee.png
[4b675b1c00f44fab8cbd16f7c8d2b87d.png]: https://img-blog.csdnimg.cn/4b675b1c00f44fab8cbd16f7c8d2b87d.png
[78e994252fc741568bbb9ddc4902679d.png]: https://img-blog.csdnimg.cn/78e994252fc741568bbb9ddc4902679d.png
[8801667bcb1e4f788001122c48d67a14.png]: https://img-blog.csdnimg.cn/8801667bcb1e4f788001122c48d67a14.png
[a9b46d22789a4c6cba4c91458c8a12ea.png]: https://img-blog.csdnimg.cn/a9b46d22789a4c6cba4c91458c8a12ea.png
[82fc798ba1ea494f9840f386033a6af9.png]: https://img-blog.csdnimg.cn/82fc798ba1ea494f9840f386033a6af9.png
[284b5951fba34c468e96315661b21ec5.png]: https://img-blog.csdnimg.cn/284b5951fba34c468e96315661b21ec5.png
[d7df1a0707a842709b4aa85da05bcee5.png]: https://img-blog.csdnimg.cn/d7df1a0707a842709b4aa85da05bcee5.png
[060c5cd1564744d68ce36b008951bbf8.png]: https://img-blog.csdnimg.cn/060c5cd1564744d68ce36b008951bbf8.png
[5dde122fd1de4aa89bd182ece7519485.png]: https://img-blog.csdnimg.cn/5dde122fd1de4aa89bd182ece7519485.png
[fbf6f294acd3451eafab33570151ca1f.png]: https://img-blog.csdnimg.cn/fbf6f294acd3451eafab33570151ca1f.png
[https_dev.mysql.com_doc_refman_5.7_en_explain-output.html]: https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
[https_dev.mysql.com_doc_refman_8.0_en_explain-output.html]: https://dev.mysql.com/doc/refman/8.0/en/explain-output.html
[977e444e8d5a4352bbc8bb5d7ecda965.png]: https://img-blog.csdnimg.cn/977e444e8d5a4352bbc8bb5d7ecda965.png
[55cfee86f1364e89b811a0972c443364.png]: https://img-blog.csdnimg.cn/55cfee86f1364e89b811a0972c443364.png
[3507d0d64bdf4f34aacf7f7f4de77e04.png]: https://img-blog.csdnimg.cn/3507d0d64bdf4f34aacf7f7f4de77e04.png
[82804bda7dc447c5bda37f9001da58f4.png]: https://img-blog.csdnimg.cn/82804bda7dc447c5bda37f9001da58f4.png
[b1e2a3bb59174202b80051bfa8b58e11.png]: https://img-blog.csdnimg.cn/b1e2a3bb59174202b80051bfa8b58e11.png
[3ee98215513949179549764453e79eb7.png]: https://img-blog.csdnimg.cn/3ee98215513949179549764453e79eb7.png
[cc7ff053fe294ea2821974db7a282511.png]: https://img-blog.csdnimg.cn/cc7ff053fe294ea2821974db7a282511.png
[ab06528cf17c40ceb51f523f88fb6817.png]: https://img-blog.csdnimg.cn/ab06528cf17c40ceb51f523f88fb6817.png
[4143f3488ffe4ad2a9d66d1b2ef96b02.png]: https://img-blog.csdnimg.cn/4143f3488ffe4ad2a9d66d1b2ef96b02.png
[cbfb899c90dc456b950ce9e7f1ede3a9.png]: https://img-blog.csdnimg.cn/cbfb899c90dc456b950ce9e7f1ede3a9.png
[42204d4eb9f946d5a27e2a562bab0983.png]: https://img-blog.csdnimg.cn/42204d4eb9f946d5a27e2a562bab0983.png
[83d5aa6d5842422482ec9916813addac.png]: https://img-blog.csdnimg.cn/83d5aa6d5842422482ec9916813addac.png
[cc864d47951b45ceba52e0576b8dd3a5.png]: https://img-blog.csdnimg.cn/cc864d47951b45ceba52e0576b8dd3a5.png
[3e99c0d632ce41038cbc9cec57e0ca33.png]: https://img-blog.csdnimg.cn/3e99c0d632ce41038cbc9cec57e0ca33.png
[bc8f8d3848ca489e981ab793d9fde371.png]: https://img-blog.csdnimg.cn/bc8f8d3848ca489e981ab793d9fde371.png
[fd4957cbc6e145ab922090427eaa9fdd.png]: https://img-blog.csdnimg.cn/fd4957cbc6e145ab922090427eaa9fdd.png
[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
[b743ff98781641ce9e349f5d06716016.png]: https://img-blog.csdnimg.cn/b743ff98781641ce9e349f5d06716016.png
[5930d116cf504b78bdae049ced26af8a.png]: https://img-blog.csdnimg.cn/5930d116cf504b78bdae049ced26af8a.png
[606d39f7ad6545e6b2a6c249f0a1e07e.png]: https://img-blog.csdnimg.cn/606d39f7ad6545e6b2a6c249f0a1e07e.png
[76939beefe7e412ea040d348ac096854.png]: https://img-blog.csdnimg.cn/76939beefe7e412ea040d348ac096854.png
[fc5c63802d35497bb0e36d232465bc2e.png]: https://img-blog.csdnimg.cn/fc5c63802d35497bb0e36d232465bc2e.png
[f01af07e5b9840fea8c7c3d0d3ded8b6.png]: https://img-blog.csdnimg.cn/f01af07e5b9840fea8c7c3d0d3ded8b6.png
[1c7b8c98859d4995854864720ab7978b.png]: https://img-blog.csdnimg.cn/1c7b8c98859d4995854864720ab7978b.png
[4fb73f3afc814f1ca1bfe1da39ce799f.png]: https://img-blog.csdnimg.cn/4fb73f3afc814f1ca1bfe1da39ce799f.png
[b88d2b68f09b4eb9b643080e15bc0c38.png]: https://img-blog.csdnimg.cn/b88d2b68f09b4eb9b643080e15bc0c38.png
[ddf91f1aeb954b5f8c5cc96de54eac84.png]: https://img-blog.csdnimg.cn/ddf91f1aeb954b5f8c5cc96de54eac84.png
[79ceb542714e4da5b17460aead962eb5.png]: https://img-blog.csdnimg.cn/79ceb542714e4da5b17460aead962eb5.png
[168a186ca0f54fd5b07b8727088632bb.png]: https://img-blog.csdnimg.cn/168a186ca0f54fd5b07b8727088632bb.png
[14397341c22f47e0af65f271c508be34.png]: https://img-blog.csdnimg.cn/14397341c22f47e0af65f271c508be34.png
[e52c8e5ae17440e488f4357de0a7bbe9.png]: https://img-blog.csdnimg.cn/e52c8e5ae17440e488f4357de0a7bbe9.png
[98999d32754749148ac505360db9fde1.png]: https://img-blog.csdnimg.cn/98999d32754749148ac505360db9fde1.png
[2e2a9360c8474a068f8741709a57a1f4.png]: https://img-blog.csdnimg.cn/2e2a9360c8474a068f8741709a57a1f4.png
[f6d22a03e5b2447bbcec04f4f4721451.png]: https://img-blog.csdnimg.cn/f6d22a03e5b2447bbcec04f4f4721451.png
[07a5a25cc0164e4c86fc7e44f5ae7036.png]: https://img-blog.csdnimg.cn/07a5a25cc0164e4c86fc7e44f5ae7036.png
[95964c20e664460c9c7d81976a1dd55b.png]: https://img-blog.csdnimg.cn/95964c20e664460c9c7d81976a1dd55b.png
[865a1e34d9a44fe2bee283d993c852b8.png]: https://img-blog.csdnimg.cn/865a1e34d9a44fe2bee283d993c852b8.png
[6bd5a00824cb4fa1a3b5a69759df8a00.png]: https://img-blog.csdnimg.cn/6bd5a00824cb4fa1a3b5a69759df8a00.png
[9cec1319af304f9bb8cea638bee1f619.png]: https://img-blog.csdnimg.cn/9cec1319af304f9bb8cea638bee1f619.png
[d939577155e142b6bc37ba393f88cda8.png]: https://img-blog.csdnimg.cn/d939577155e142b6bc37ba393f88cda8.png
[f906e109838142ddad64bcda860f6220.png]: https://img-blog.csdnimg.cn/f906e109838142ddad64bcda860f6220.png
[14cf3c818f354081b5ed8000a9e00383.png]: https://img-blog.csdnimg.cn/14cf3c818f354081b5ed8000a9e00383.png
[fd05a9f8594d4b55b169af24abbaea7b.png]: https://img-blog.csdnimg.cn/fd05a9f8594d4b55b169af24abbaea7b.png
[6f4839b911114f4c87a123468e201677.png]: https://img-blog.csdnimg.cn/6f4839b911114f4c87a123468e201677.png
[2f779b703cc8469783a2e2d5a1a3d78f.png]: https://img-blog.csdnimg.cn/2f779b703cc8469783a2e2d5a1a3d78f.png
[5e6080087ba24c249986bbec0da54794.png]: https://img-blog.csdnimg.cn/5e6080087ba24c249986bbec0da54794.png
[e45e7738398c43258579cc69656b3317.png]: https://img-blog.csdnimg.cn/e45e7738398c43258579cc69656b3317.png
[73d51c1459b149e7937bef9c98978037.png]: https://img-blog.csdnimg.cn/73d51c1459b149e7937bef9c98978037.png
[1d808e5fe2b14ecb8e195f83a4a7c97e.png]: https://img-blog.csdnimg.cn/1d808e5fe2b14ecb8e195f83a4a7c97e.png
[3c290693f19c4d168f5ed5cfb67a7d62.png]: https://img-blog.csdnimg.cn/3c290693f19c4d168f5ed5cfb67a7d62.png
[b30a3dbee652428093647c5d8f60f033.png]: https://img-blog.csdnimg.cn/b30a3dbee652428093647c5d8f60f033.png
[b762601541644457868aaf31a2c2330e.png]: https://img-blog.csdnimg.cn/b762601541644457868aaf31a2c2330e.png
[cef7c41f489b481aab504737f3a3ac21.png]: https://img-blog.csdnimg.cn/cef7c41f489b481aab504737f3a3ac21.png
[19f5486a9be14f919d50a9a8a3583760.png]: https://img-blog.csdnimg.cn/19f5486a9be14f919d50a9a8a3583760.png
[63785595326040f0b363f83b06fcd267.png]: https://img-blog.csdnimg.cn/63785595326040f0b363f83b06fcd267.png
[a96de9d1011b41f9928fd053647d3991.png]: https://img-blog.csdnimg.cn/a96de9d1011b41f9928fd053647d3991.png
[e11bce7138b74becbe28def29b82fbdd.png]: https://img-blog.csdnimg.cn/e11bce7138b74becbe28def29b82fbdd.png
[62256d49d017406c9c53ce7ef3694528.png]: https://img-blog.csdnimg.cn/62256d49d017406c9c53ce7ef3694528.png
[cd7233f6ebab416e80a9a1a4f327e0fb.png]: https://img-blog.csdnimg.cn/cd7233f6ebab416e80a9a1a4f327e0fb.png