MySQL执行计划 type的秘密

╰+哭是因爲堅強的太久メ 2021-11-10 05:38 438阅读 0赞

**目录**

执行计划 type 列的访问类型

MySQL 执行计划 Extra列 和 type列区别

示例1、type为 index、all、ref情况

SQL1、type：index，Extra：Using index

SQL2、type：ref，Extra：Using where；Using index

SQL3、type：all，Extra：Using where

SQL4、type：ref，Extra：Using where

示例1总结：Where条件运行方式

示例2、type为 const（常数）

创建表

SQL

执行计划

示例分析

--------------------

# 执行计划 type 列的访问类型 #

访问类型从全表扫描到索引扫描（index）、范围扫描（range）、唯一索引查询、常数（const）引用等。

速度是从慢到快，扫描的行数也是从大到小。

# [MySQL 执行计划 Extra列 和 type列区别][MySQL _ Extra_ _ type] #

很容易把 Extra 列的 “Using index”  和 type 列的 “index” 搞混淆。其实这两者完全不同，type 列和覆盖索引毫无关系；它只是表示这个查询访问数据的方式，或者说是 MySQL 查找行的方式。MySQL 手册中称之为连接方式（join type）。

# 示例1、type为 index、all、ref情况 #

接着上篇文章的示例：[https://blog.csdn.net/ruanhao1203/article/details/98061034\#%E5%BA%94%E7%94%A8%E8%A6%86%E7%9B%96%E7%B4%A2%E5%BC%95][https_blog.csdn.net_ruanhao1203_article_details_98061034_E5_BA_94_E7_94_A8_E8_A6_86_E7_9B_96_E7_B4_A2_E5_BC_95]

例如创建表 fgsy 字段如下

![20190801164022798.png][]

覆盖索引如下

![20190801164043332.png][]

## SQL1、type：index，Extra：Using index ##

如下图，只有select里面选择的字段在覆盖索引内，才可以使用覆盖索引。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70][]

## SQL2、type：ref，Extra：Using where；Using index ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 1][]

## SQL3、type：all，Extra：Using where ##

下面这种方式就不能运用覆盖索引，因为无法覆盖 所有列。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 2][]

## SQL4、type：ref，Extra：Using where ##

加上where条件的查询

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 3][]

## 示例1总结：Where条件运行方式 ##

MySQL使用Where条件的三种方式，从好到坏依次为：

1. 在索引中使用 Where 条件 来过滤不匹配的记录。这是存储引擎层完成的。示例的**SQL4** 就是这种情况。

2. 使用索引覆盖扫描（在 Extra 列中出现了 Using index）来返回记录，直接从索引中过滤不需要的记录并返回命中的结果。这是在MySQL 服务器层完成的，但无须再回表查询记录。示例的**SQL2** 就是这种情况。

3. 从数据表中返回数据，然后过滤不满足条件的记录（在Extra列中出现 Using Where）。这在 MySQL 服务器层完成，MySQL需要先从数据表都护记录然后过滤。示例的**SQL3**就是这种情况。

示例**SQL1** 最高效，因为用了覆盖索引，所以type为index，获取行数据直接从索引上获取的。

# 示例2、type为 const（常数） #

## 创建表 ##

t\_left

![20190802155138821.png][]

数据

![20190802155313239.png][]

t\_right

![20190802155206145.png][]

t\_right索引

![20190802155233997.png][]

数据

![20190802155332605.png][]

## SQL ##

SELECT a.name, b.`name` FROM t_left a 
    INNER JOIN t_right b ON a.id = b.a_id
    where a.id = 1

## 执行计划 ##

![20190802155438238.png][]

## 示例分析 ##

此SQL语句分两步执行查询，也就是上面执行计划的两行输出。第一步先从 a 表找到需要的行。因为 id字段上有主键索引，所以 MySQL 优化器知道这只会返回一行数据，优化器在生成执行计划的时候，就已经通过索引信息知道将会返回多少行数据。因为优化器已经明确了知道有多少个值需要索引查询，所以这里的行数据访问类型是 const。

在执行计划的第二步，MySQL将第一步返回的id列当作一个已知取值的列来处理。因为 a\_id上也有索引，同上理解，也就是 const了。

[MySQL _ Extra_ _ type]: https://blog.csdn.net/ruanhao1203/article/details/98072833
[https_blog.csdn.net_ruanhao1203_article_details_98061034_E5_BA_94_E7_94_A8_E8_A6_86_E7_9B_96_E7_B4_A2_E5_BC_95]: https://blog.csdn.net/ruanhao1203/article/details/98061034#%E5%BA%94%E7%94%A8%E8%A6%86%E7%9B%96%E7%B4%A2%E5%BC%95
[20190801164022798.png]: /images/20211109/fdce42181c564c97862b37d41776015d.png
[20190801164043332.png]: /images/20211109/306e2e32791b4714a7490d12f14bf649.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70]: /images/20211109/c9df34972b7a4fa7b5d365655f705a2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 1]: /images/20211109/92138f4d9439414296f4888fe112147e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 2]: /images/20211109/c3c26e3c7b51440b896cd5f1ff8d1a08.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1YW5oYW8xMjAz_size_16_color_FFFFFF_t_70 3]: /images/20211109/77b3ec5d8c32475e9642b7206907c7ef.png
[20190802155138821.png]: /images/20211109/6d0fac49908c407286518c0c9edf71c6.png
[20190802155313239.png]: /images/20211109/e79b171546314a228725c265d77083f4.png
[20190802155206145.png]: /images/20211109/a82979b835534576a7412b549af172ae.png
[20190802155233997.png]: /images/20211109/f4cf2f5f534b49c2a51e355c90ae4aa7.png
[20190802155332605.png]: /images/20211109/b3a3b9df62ad4a1a8cb979d65e1416d5.png
[20190802155438238.png]: /images/20211109/3680a12aac3647cc881a7c0bdb70688c.png