MySQL中通过EXPLAIN如何分析SQL的执行计划详解

以你之姓@ 2022-01-20 12:57 182阅读 0赞

转载：[https://www.jb51.net/article/145515.htm][https_www.jb51.net_article_145515.htm]

**前言**

在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。

[![2018081309265811.png][]][2018081309265811.png]

下面分别对EXPLAIN命令结果的每一列进行说明：

**.select\_type:**表示SELECT的类型，常见的取值有：

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SIMPLE</td> 
   <td>简单表，不使用表连接或子查询</td> 
  </tr> 
  <tr> 
   <td>PRIMARY</td> 
   <td>主查询，即外层的查询</td> 
  </tr> 
  <tr> 
   <td>UNION</td> 
   <td>UNION中的第二个或者后面的查询语句</td> 
  </tr> 
  <tr> 
   <td>SUBQUERY</td> 
   <td>子查询中的第一个</td> 
  </tr> 
 </tbody> 
</table>

**.table:**输出结果集的表（表别名）

**.type:**表示MySQL在表中找到所需行的方式，或者叫访问类型。常见访问类型如下，从上到下，性能由差到最好：

<table> 
 <thead> 
  <tr> 
   <th>ALL</th> 
   <th>全表扫描</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>index</td> 
   <td>索引全扫描</td> 
  </tr> 
  <tr> 
   <td>range</td> 
   <td>索引范围扫描</td> 
  </tr> 
  <tr> 
   <td>ref</td> 
   <td>非唯一索引扫描</td> 
  </tr> 
  <tr> 
   <td>eq_ref</td> 
   <td>唯一索引扫描</td> 
  </tr> 
  <tr> 
   <td>const,system</td> 
   <td>单表最多有一个匹配行</td> 
  </tr> 
  <tr> 
   <td>NULL</td> 
   <td>不用扫描表或索引</td> 
  </tr> 
 </tbody> 
</table>

**1、type=ALL，全表扫描，MySQL遍历全表来找到匹配行**

一般是没有where条件或者where条件没有使用索引的查询语句

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>active=0;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309265812.png][]][2018081309265812.png]

**2、type=index，索引全扫描，MySQL遍历整个索引来查询匹配行，并不会扫描表**

一般是查询的字段都有索引的查询语句

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>store_id </code><code>FROM</code> <code>customer;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309265813.png][]][2018081309265813.png]

**3、type=range，索引范围扫描，常用于<、<=、>、>=、between等操作**

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>customer_id&gt;=10 </code><code>AND</code> <code>customer_id&lt;=20;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309265914.png][]][2018081309265914.png]

**注意**这种情况下比较的字段是需要加索引的，如果没有索引，则MySQL会进行全表扫描，如下面这种情况，create\_date字段没有加索引：

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>create_date&gt;=</code><code>'2006-02-13'</code> <code>;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309265915.png][]][2018081309265915.png]

**4、type=ref，使用非唯一索引或唯一索引的前缀扫描，返回匹配某个单独值的记录行**

`store_id`字段存在普通索引（非唯一索引）

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>store_id=10;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309270016.png][]][2018081309270016.png]

ref类型还经常会出现在join操作中：

customer、payment表关联查询，关联字段`customer.customer_id`（主键），`payment.customer_id`（非唯一索引）。表关联查询时必定会有一张表进行全表扫描，此表一定是几张表中记录行数最少的表，然后再通过非唯一索引寻找其他关联表中的匹配行，以此达到表关联时扫描行数最少。

![2018081309270017.png][]

因为customer、payment两表中customer表的记录行数最少，所以customer表进行全表扫描，payment表通过非唯一索引寻找匹配行。

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer customer </code><code>INNER</code> <code>JOIN</code> <code>payment payment </code><code>ON</code> <code>customer.customer_id = payment.customer_id;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309270118.png][]][2018081309270118.png]

**5、type=eq\_ref，类似ref，区别在于使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配**

eq\_ref一般出现在多表连接时使用primary key或者unique index作为关联条件。

film、film\_text表关联查询和上一条所说的基本一致，只不过关联条件由非唯一索引变成了主键。

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>film film </code><code>INNER</code> <code>JOIN</code> <code>film_text film_text </code><code>ON</code> <code>film.film_id = film_text.film_id;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309270119.png][]][2018081309270119.png]

**6、type=const/system，单表中最多有一条匹配行，查询起来非常迅速，所以这个匹配行的其他列的值可以被优化器在当前查询中当作常量来处理**

const/system出现在根据主键primary key或者 唯一索引 unique index 进行的查询

根据主键primary key进行的查询：

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>customer_id =10;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309270120.png][]][2018081309270120.png]

根据唯一索引unique index进行的查询：

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>customer </code><code>WHERE</code> <code>email =</code><code>'MARY.SMITH@sakilacustomer.org'</code><code>;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

[![2018081309270121.png][]][2018081309270121.png]

[![2018081309270122.png][]][2018081309270122.png]

**7、type=NULL，MySQL不用访问表或者索引，直接就能够得到结果**

[![2018081309270123.png][]][2018081309270123.png]

**.possible\_keys: **表示查询可能使用的索引

**.key: **实际使用的索引

**.key\_len: **使用索引字段的长度

**.ref: **使用哪个列或常数与key一起从表中选择行。

**.rows: **扫描行的数量

**.filtered: **存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例(百分比)

**.Extra: **执行情况的说明和描述，包含不适合在其他列中显示但是对执行计划非常重要的额外信息

最主要的有一下三种：

<table> 
 <thead> 
  <tr> 
   <th>Using Index</th> 
   <th>表示索引覆盖，不会回表查询</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Using Where</td> 
   <td>表示进行了回表查询</td> 
  </tr> 
  <tr> 
   <td>Using Index Condition</td> 
   <td>表示进行了ICP优化</td> 
  </tr> 
  <tr> 
   <td>Using Flesort</td> 
   <td>表示MySQL需额外排序操作, 不能通过索引顺序达到排序效果</td> 
  </tr> 
 </tbody> 
</table>

**什么是ICP？**

MySQL5.6引入了Index Condition Pushdown（ICP）的特性，进一步优化了查询。Pushdown表示操作下放，某些情况下的条件过滤操作下放到存储引擎。

[?][Link 1]

<table> 
 <tbody> 
  <tr> 
   <td> <p>1</p> </td> 
   <td> <p><code>EXPLAIN </code><code>SELECT</code> <code>* </code><code>FROM</code> <code>rental </code><code>WHERE</code> <code>rental_date=</code><code>'2005-05-25'</code> <code>AND</code> <code>customer_id&gt;=300 </code><code>AND</code> <code>customer_id&lt;=400;</code></p> </td> 
  </tr> 
 </tbody> 
</table>

**在5.6版本之前：**

优化器首先使用复合索引idx\_rental\_date过滤出符合条件`rental_date='2005-05-25'`的记录，然后根据复合索引idx\_rental\_date回表获取记录，最终根据条件`customer_id>=300 AND customer_id<=400`过滤出最后的查询结果（在服务层完成）。

**在5.6版本之后：**

MySQL使用了ICP来进一步优化查询，在检索的时候，把条件`customer_id>=300 AND customer_id<=400`也推到存储引擎层完成过滤，这样能够降低不必要的IO访问。Extra为`Using index condition`就表示使用了ICP优化。

[![2018081309270224.png][]][2018081309270224.png]

参考

《深入浅出MySQL》

**总结**

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。

[https_www.jb51.net_article_145515.htm]: https://www.jb51.net/article/145515.htm
[2018081309265811.png]: https://files.jb51.net/file_images/article/201808/2018081309265811.png
[Link 1]: https://www.jb51.net/article/145515.htm#
[2018081309265812.png]: https://files.jb51.net/file_images/article/201808/2018081309265812.png
[2018081309265813.png]: https://files.jb51.net/file_images/article/201808/2018081309265813.png
[2018081309265914.png]: https://files.jb51.net/file_images/article/201808/2018081309265914.png
[2018081309265915.png]: https://files.jb51.net/file_images/article/201808/2018081309265915.png
[2018081309270016.png]: https://files.jb51.net/file_images/article/201808/2018081309270016.png
[2018081309270017.png]: https://files.jb51.net/file_images/article/201808/2018081309270017.png
[2018081309270118.png]: https://files.jb51.net/file_images/article/201808/2018081309270118.png
[2018081309270119.png]: https://files.jb51.net/file_images/article/201808/2018081309270119.png
[2018081309270120.png]: https://files.jb51.net/file_images/article/201808/2018081309270120.png
[2018081309270121.png]: https://files.jb51.net/file_images/article/201808/2018081309270121.png
[2018081309270122.png]: https://files.jb51.net/file_images/article/201808/2018081309270122.png
[2018081309270123.png]: https://files.jb51.net/file_images/article/201808/2018081309270123.png
[2018081309270224.png]: https://files.jb51.net/file_images/article/201808/2018081309270224.png