手把手教你彻底理解MySQL的explain关键字

素颜马尾好姑娘i 2023-01-21 10:27 192阅读 0赞

数据库是程序员必备的一项基本技能，基本每次面试必问。对于刚出校门的程序员，你只要学会如何使用就行了，但越往后工作越发现，仅仅会写sql语句是万万不行的。写出的sql，如果性能不好，达不到要求，可能会阻塞整个系统，那对于整个系统来讲是致命的。

所以如何判断你的sql写的好不好呢？毕竟只有先知道sql写的好不好，才能再去考虑如何优化的问题。

MySQL官方就给我们提供了很多sql分析的工具，这里我们主要说一下EXPLAIN。

以下是基于MySQL5.7.28版本进行分析的，不同版本之间略有差异。

![在这里插入图片描述][20210515170848630.png_pic_center]

#### 1.1 概念 ####

使用EXPLAIN关键字可以**模拟优化器**执行sql语句，从而知道MySQL是如何处理你的语句，分析你的查询语句或者表结构的性能瓶颈。

用法：EXPLAIN+ sql语句

EXPLAIN执行后返回的信息如下：

![在这里插入图片描述][20210515170857418.png_pic_center]

各个字段的大致含义如下：

*  id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.
 *  select\_type: SELECT 查询的类型.
 *  table: 查询的是哪个表
 *  partitions: 匹配的分区
 *  type: join 类型
 *  possible\_keys: 此次查询中可能选用的索引
 *  key: 此次查询中确切使用到的索引.
 *  key\_len: 查询优化器使用了索引的字节数.
 *  ref: 哪个字段或常数与 key 一起被使用
 *  rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
 *  filtered: 表示此查询条件所过滤的数据的百分比
 *  extra: 额外的信息

#### 1.2 准备工作 ####

新建一个数据库test，执行下面的sql语句

CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
    INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));
    INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
    INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
    INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));

下面一一解释各列的含义。

#### 1.3 id ####

select查询的序列号，包含一组数字，表示查询中执行select子句的顺序或操作表的顺序。大致分为下面几种情况

（1）**id相同，执行顺序由上至下**

![在这里插入图片描述][20210515170912347.png_pic_center]

上面的查询语句，三个id都为1，具有相同的优先级，执行顺序由上而下，具体执行顺序由优化器决定，这里执行顺序为t1，t2，t3。

（2）**id不同，数字越大优先级越高**

![在这里插入图片描述][20210515170919699.png_pic_center]

如果sql中存在子查询，那么id的序号会递增，id越大越先被执行。如上图，执行顺序是t3、t1、t2，也就是说，最里面的子查询最先执行，由里往外执行。

在我测试的时候，无意中发现，下面的语句，一**个使用的是IN关键字，一个使用的=运算符，但使用EXPLAIN执行后，结果天壤之别。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center]

这说明使用IN嵌套子查询，它是按顺序来执行的，也就是说每执行一次最外层子查询，里面的子查询都会被重复执行，这好像和我的理解差很多啊（我一直以为是先执行最里面的子查询，再执行外面的）。

具体可以看看这篇文章，我觉得讲的大概算是明白了。[https://segmentfault.com/a/1190000005742843][https_segmentfault.com_a_1190000005742843]。这里就不再继续赘述了。

**千万别用IN，使用JOIN或者EXISTS代替它**

（3）**id存在相同的和不同的**

在上面语句的基础上，增加一个IN的子查询，执行结果如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 1]

执行顺序为t3、t1、t2、t4。值越大的越先执行，相同值的从上往下执行。

#### 1.4 select\_type ####

select\_type表示查询的类型，主要是为了区分普通查询、子查询、联合查询等复杂查询。分为以下几种类型：

（1）**SIMPLE**

简单的select查询，查询中不包含子查询或者UNION。

（2）**PRIMARY**

查询中若包含任何复杂的子查询，那么最外层的查询被标记为PRIMARY。

（3）**DERIVED**

在from子句中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表中。

（4）**SUBQUERY**

在select或where子句中包含了子查询，该子查询被标记为SUBQUERY。

（5）**UNION**

若第二个select查询语句出现在UNION之后，则被标记为UNION。若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED

（6）**UNION RESULT**

从UNION表获取结果的SELECT。

上面的前三种在上一小节已经出现过了，看看后面这三种

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 2]

可以看到id列出现了一个NULL，这是上面没讲到的。**一般来说，特殊情况下，如果某行语句引用了其他多行结果集的并集，则该值可以为 NULL**。

#### 1.5 table ####

这个没啥好讲的，表示这个查询是基于哪种表的。并不一定是真实存在的表，比如上面出现的DERIVED和<union1,2>，一般来说会出现下面的取值：

（1）**<union a,b>**：输出结果中编号为 a 的行与编号为 b 的行的结果集的并集。

（2）**< derived a>**：输出结果中编号为 a 的行的结果集，derived 表示这是一个派生结果集，如 FROM 子句中的查询。

（3）**< subquery a>**：输出结果中编号为 a 的行的结果集，subquery 表示这是一个物化子查询。

#### 1.6 partitions ####

查询时匹配到的分区信息，对于非分区表值为`NULL`，当查询的是分区表时，`partitions`显示分区表命中的分区情况。

根据官方文档，在创建表的时候，指定不同分区存放的id值范围不同。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 3]

插入测试数据，让id值分布在四个分区内。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 4]

执行查询输出结果。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 5]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 6]

#### 1.7 type ####

type是查询的访问类型，是较为重要的一个指标，性能从最好到最坏依次是 system > const > eq\_ref > ref > fulltext > ref\_or\_null > index\_merge > unique\_subquery > index\_subquery > range > index > ALL。

一般来说，得保证查询至少到达range级别，最好能达到ref。

（1）**system**

当表仅存在一行记录时（系统表），数据量很少，速度很快，这是一种很特殊的情况，不常见。

（2）**const**

当你的查询条件是一个主键或者唯一索引（UNION INDEX）并且值是常量的时候，查询速度非常快，因为只需要读一次表。

![在这里插入图片描述][20210515172645941.png_pic_center]

给t1表的content列增加一个唯一索引

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 7]  
![在这里插入图片描述][20210515171116658.png_pic_center]

（3）\*\*eq\_ref \*\*

除了system和const，性能最好的就是eq\_ref了。唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。

![在这里插入图片描述][20210515172706498.png_pic_center]

（4）**ref**

非唯一性索引扫描，返回匹配某个单独值的所有行。区别于eq\_ref，ref表示使用除`PRIMARY KEY` 和`UNIQUE` index 之外的索引，即非唯一索引，查询的结果可能有多个。可以使用 = 运算符或者<=> 运算符。

在t2表的content列加上普通索引

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 8]

进行查询

![在这里插入图片描述][20210515172726593.png_pic_center]

（5）**fulltext**

查询时使用 fulltext 索引。

（6）**ref\_or\_null**

对于某个字段既需要关联条件，也需要null 值的情况下。查询优化器会选择用ref\_or\_null 连接查询。

![在这里插入图片描述][20210515172734420.png_pic_center]

（7）**index\_merge**

在查询过程中需要多个索引组合使用，通常出现在有or 关键字的sql 中。

（8）**unique\_subquery**

该联接类型类似于index\_subquery。子查询中的唯一索引。在某些in子查询里，用于替换eq\_ref，比如下面的查询语句

value IN (SELECT primary_key FROM single_table WHERE some_expr)

（9）**index\_subquery**

\[图片上传中…(19.png-e55cec-1621069077487-0)\]  
利用索引来关联子查询，不再全表扫描。用于**非唯一索引**，子查询可以返回重复值。类似于unique\_subquery，但用于非唯一索引

value IN (SELECT key_column FROM single_table WHERE some_expr)

（10）**range**

只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引，一般就是在你的where 语句中出现  
了between、<、>、in 等的查询，这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而  
结束语另一点，不用扫描全部索引。

举个例子，t3表中id字段为主键，有PRIMARY索引，content字段没有建立索引，查询时使用id作为条件，结果如下

![在这里插入图片描述][20210515172742646.png_pic_center]

使用content作为条件，结果如下

![在这里插入图片描述][20210515172748981.png_pic_center]

**所以，只有对设置了索引的字段，做范围检索 `type` 才是 `range`。**

（11）**index**

sql语句使用了索引，但没有通过索引进行过滤，一般是使用了覆盖索引或者利用索引进行了排序分组。

index和ALL都是读全表，区别在于index是遍历索引树读取，ALL是从硬盘读取。index通常比ALL更快，因为索引文件通常比数据文件小。

举个例子，查询t3表主键id，结果如下

![在这里插入图片描述][20210515172755551.png_pic_center]

（12）**ALL**

全表扫描，性能最差。

![在这里插入图片描述][20210515172808535.png_pic_center]

#### 1.8 possible\_keys ####

查询时可能使用的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出。注意是可能，实际查询时不一定会用到。

#### 1.9 key ####

查询时实际使用的索引，没有使用索引则为NULL。**查询时若使用了覆盖索引，则该索引只出现在key字段中。**

举个例子，trb1表中有一个组合索引(age, name)，那么当你的查询列和索引的个数和顺序一致时，查询结果如下：

![在这里插入图片描述][20210515172816198.png_pic_center]

#### 1.10 key\_len ####

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。**在不损失精确性的情况下，长度越短越好**。

key\_len显示的值是索引字段可能的最大长度，并非实际使用长度，即key\_len是根据表定义计算得到，不是通过表内检索。

key\_len 字段能够帮你检查是否充分的利用上了索引。ken\_len 越长，说明索引使用的越充分。

注意：`key_len`只计算`where`条件中用到的索引长度，而排序和分组即便是用到了索引，也不会计算到`key_len`中。

举个例子，有表trb1，存在以下字段，以及一个组合索引idx\_age\_name

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 9]

下面查询语句的执行结果

![在这里插入图片描述][2021051517283366.png_pic_center]

![在这里插入图片描述][20210515172840247.png_pic_center]

![在这里插入图片描述][20210515172850702.png_pic_center]

key\_len的值为153、158、null。如何计算：

①先看索引上字段的类型+长度。比如int=4 ; varchar(50) = 50 ; char(50) = 50。

②如果是varchar 或者char 这种字符串字段，视字符集要乘不同的值，比如utf-8 要乘3,GBK 要乘2。

③varchar 这种动态字符串要加2 个字节。

④允许为空的字段要加1 个字节。

第一条：key\_len = name的字节长度 = 50 \* 3 + 2 + 1 = 153

第二条：key\_len = age 的字节长度 + name 的字节长度= 4 +1 + ( 50\*3 + 2 + 1)= 5 + 153 = 158。（使用的索引更充分，查询结果更精确，但消耗更大）

第三条：索引失效了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 10]

#### 1.11 ref ####

显示索引的哪一列被使用了，常见的取值有：const， func，null，字段名。

*  当使用常量等值查询，显示`const`，
 *  当关联查询时，会显示相应关联表的`关联字段`
 *  如果查询条件使用了`表达式`、`函数`，或者条件列发生内部隐式转换，可能显示为`func`
 *  其他情况`null`

举个例子，t3表的content字段有普通索引，下面的查询语句结果如下

![在这里插入图片描述][20210515172904443.png_pic_center]

#### 1.12 rows ####

rows 列表示 MySQL 认为它执行查询时可能需要读取的行数，一般情况下这个值越小越好！

#### 1.13 filtered ####

`filtered` 是一个百分比的值，表示符合条件的记录数的百分比。简单点说，这个字段表示存储引擎返回的数据在经过过滤后，剩下满足条件的记录数量的比例。

在`MySQL.5.7`版本以前想要显示`filtered`需要使用`explain extended`命令。`MySQL.5.7`后，默认`explain`直接显示`partitions`和`filtered`的信息。

#### 1.14 Extra ####

其他额外的信息。

（1）**Using filesort**

说明mysql 会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL 中无法利用索引完成的排序操作称为“文件排序”。

举个例子，trb1表建立一个组合索引

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 11]

下面的查询出现filesort ：

![在这里插入图片描述][20210515172918764.png_pic_center]

按照组合索引的顺序，是name、age、purchased，而上面的查询语句，没有使用中间的age，所以在order by的时候索引失效了。**通常这种情况是需要进行优化的**。

修改一下上面的sql语句，让索引不失效。

![在这里插入图片描述][2021051517292524.png_pic_center]

（2）**Using temporary**

使了用临时表保存中间结果,MySQL 在对查询结果排序时使用临时表。常见于排序order by 和分组查询group by。

![在这里插入图片描述][20210515172931427.png_pic_center]

这条sql语句用了临时表，又用了文件排序，在数据量非常大的时候效率是很低的，需要进行优化。

![在这里插入图片描述][20210515172938548.png_pic_center]

**所以在使用group by 和 order by的时候，列的数量和顺序尽量和索引的一样。**

（3）**Using index**

Using index 表示相应的select 操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，可以提高效率。

如果同时出现using where，表明索引被用来执行索引键值的查找。如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找。

还是使用上面的trb1表举例子

![在这里插入图片描述][20210515172945198.png_pic_center]

只出现了Using index，说明索引用来读取数据而不是执行查找。

![在这里插入图片描述][20210515172951100.png_pic_center]

出现了Using where，说明索引被用来执行查找。

（4）**Using where**

表示查询时有索引被用来进行where过滤。

（5）**Using join buffer**

查询时使用了连接缓存。

（6）**impossible where**

查询语句的where条件总是为false，举个例子

![在这里插入图片描述][20210515172956850.png_pic_center]

一般情况下不会出现这种。

关于Extra字段，有很多取值，这里就不一一列举了，具体可以看官方文档。

参考资料：[https://dev.mysql.com/doc/refman/5.7/en/explain-output.html][https_dev.mysql.com_doc_refman_5.7_en_explain-output.html]

[20210515170848630.png_pic_center]: /images/20221020/e5d2b4813e2b44e7b3d0b892842b1a31.png
[20210515170857418.png_pic_center]: /images/20221020/f84ef8f52d6c4a748396a97dba30e94d.png
[20210515170912347.png_pic_center]: /images/20221020/f0b6aedc3eef4bba813053893e5208c8.png
[20210515170919699.png_pic_center]: /images/20221020/3d5b4aade28343cab45391f60c05b7f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center]: /images/20221020/36cf45bec3134827a896caa3c60c8619.png
[https_segmentfault.com_a_1190000005742843]: https://segmentfault.com/a/1190000005742843
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221020/74024a6f346e452591e470ef95e04802.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221020/1d8371c362404aab822529763a40feed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221020/30710ae261e84823bf9abb96a1ee3b9b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221020/87a7b081f9374a58a513b774d8f5d2ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221020/2871b0af2daf4dc1886e3579d85faa20.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221020/815e47b46d7f497288906299232f3202.png
[20210515172645941.png_pic_center]: /images/20221020/e6026c2b8fdd4ef3bc43da1bbe95cee4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221020/ee50b20bbb754ebba8210cb6ec7c7390.png
[20210515171116658.png_pic_center]: /images/20221020/ed352ad9fab540d2b0060f406dfd0748.png
[20210515172706498.png_pic_center]: /images/20221020/1b10598925644d4ebc18df2c314827b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221020/99b1d8c9160f42fc8bb8e3f3f7232f5c.png
[20210515172726593.png_pic_center]: /images/20221020/ad92d988335e4f5e9a876993cde4b5ad.png
[20210515172734420.png_pic_center]: /images/20221020/eb5e8cfce9f94c7cb164212508ea1e8a.png
[20210515172742646.png_pic_center]: /images/20221020/571676d93f004c1c886f86ee7ddcdf7f.png
[20210515172748981.png_pic_center]: /images/20221020/952e2ac0c23f43d492bb61eb207c24e3.png
[20210515172755551.png_pic_center]: /images/20221020/f783e28e61ba430d955a8092cc11528c.png
[20210515172808535.png_pic_center]: /images/20221020/d293fd48952d4ed8ac5878b1a991b95b.png
[20210515172816198.png_pic_center]: /images/20221020/7b76d8a5deaa450fbfd4bdf1e25af02b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221020/acf3a4e1d6924651b9bcd9f5a5ebefe3.png
[2021051517283366.png_pic_center]: /images/20221020/018d46972f4c4c69865c41434d66acbc.png
[20210515172840247.png_pic_center]: /images/20221020/87ee159aba2e463989968cdaf7914324.png
[20210515172850702.png_pic_center]: /images/20221020/16b5e1ace726432e88a588ba4c0a2c13.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221020/de9fdf22141940fb81543bf8175d1ad9.png
[20210515172904443.png_pic_center]: /images/20221020/f88558fcfe5e47f180e6728d09010b4e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FfaGVsbG93b3Jk_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221020/4995a1f555cc419ea13095e3cacdaf2a.png
[20210515172918764.png_pic_center]: /images/20221020/de1b6118c7f24c0cb9bd9ba82fc8a453.png
[2021051517292524.png_pic_center]: /images/20221020/64118bf521ce4af8be68c8dfd7cde1d7.png
[20210515172931427.png_pic_center]: /images/20221020/fc7e7797d15c426cafee9be622e54a22.png
[20210515172938548.png_pic_center]: /images/20221020/59a3d5d1bd48483e9a0a8fd107d26b4d.png
[20210515172945198.png_pic_center]: /images/20221020/d8795695e0e64860b4d852c73960374d.png
[20210515172951100.png_pic_center]: /images/20221020/a62fedf4f0d141d09ae16dc7de2f37d9.png
[20210515172956850.png_pic_center]: /images/20221020/25ef826805c045ec814e3840edc08088.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