前言
什么是执行计划？简而言之，就是 SQL 在数据库中执行时的表现情况，通常用于 SQL 性能分析、优化和加锁分析等场景，执行过程会在 MySQL 查询过程中由解析器，预处理器和查询优化器共同生成。在MySQL中使用 explain 关键字来查看。
执行计划能告诉我们什么？她可以用来分析SQL语句和表结构的性能瓶颈。通过分析explain的输出结果集，可以了解到诸如关联查询的执行顺序、查询操作的操作类型、哪些索引可以被命中、哪些索引实际被命中、每张表有多少记录参与查询等信息。接下来，我们将介绍在explain结果集中每一列的意义。
EXPLAIN 中的列
mysql> explain select * from servers;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL | 1 | NULL |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
1 row in set (0.03 sec)
expain执行后输出的结果集包含10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows和Extra，下面对这些字段进行解释。
| 列名 | 说明 |
|---|---|
| id | 执行编号，标识select所属的行。如果在语句中没子查询或关联查询，只有唯一的select，每行都将显示1。否则，内层的select语句一般会顺序编号，对应于其在原始语句中的位置 |
| select_type | 显示本行是简单或复杂select。如果查询有任何复杂的子查询，则最外层标记为PRIMARY（DERIVED、UNION、UNION RESUlT） |
| table | 访问引用哪个表（引用某个查询，如“derived3”） |
| type | 数据访问/读取操作类型（ALL、index、range、ref、eq_ref、const/system、NULL） |
| possible_keys | 揭示哪一些索引可能有利于高效的查找 |
| key | 显示mysql决定采用哪个索引来优化查询 |
| key_len | 显示mysql在索引里使用的字节数 |
| ref | 显示了之前的表在key列记录的索引中查找值所用的列或常量 |
| rows | 为了找到所需的行而需要读取的行数，估算值，不精确。通过把所有rows列值相乘，可粗略估算整个查询会检查的行数 |
| Extra | 额外信息，如using index、filesort等 |
id 和select_type
每个被独立执行的操作的标识，表示各个SQL片段被操作的顺序；在嵌套查询中id越大的语句越先执行，如果相同，那么按照从上到下的顺序执行。该值可能为NULL，如果这一行用来说明的是其他行的联合结果。
-- 查看在研发部并且名字以Jef开头的员工，经典查询
explain select e.no, e.name from emp e left join dept d on e.dept_no = d.no where e.name like 'Jef%' and d.name = '研发部';
select_type表示查询的类型，其枚举值和说明见下表：
| 类型 | 说明 |
|---|---|
| simple | 简单SELECT，不包含子查询和union |
| primary | 包含union或者子查询，最外层的部分标记为primary |
| subquery | 一般子查询中的子查询被标记为subquery，也就是位于select列表中的查询 |
| derived | 派生表——该临时表是从子查询派生出来的，位于from中的子查询 |
| union | 位于union中第二个或者其以后的子查询被标记为union，第一个就被标记为primary。若union位于from中，则标记为derived。取决于外面的查询 |
| union result | 用来从匿名临时表里检索结果的select子句被标记为union result |
| dependent union | 顾名思义，首先需要满足UNION的条件，及UNION中第二个以及后面的SELECT语句，同时该语句依赖外部的查询 |
| subquery | 子查询中第一个SELECT语句 |
| dependent subquery | 子查询中的第一个 select，取决于外侧的查询，一般是 in 中的子查询。 |
该示例中，in子查询的select_type被标记为dependent subquery ，主查询被标记为primary。
此图展示了 union 和 union result 的 SQL 案例。
table
对应行正在访问哪一个表，可以是表名或者别名
- 关联优化器会为查询选择关联顺序，左侧深度优先
- 当from中有子查询的时候，表名是derivedN的形式，N指向子查询，也就是explain结果中的下一列
- 当有union result的时候，表名是union 1,2等的形式，1,2表示参与union的query id
注意：MySQL对待这些表和普通表一样，但是这些“临时表”是没有任何索引的。
type
type显示的是各个表之间的关联类型，表示MySQL决定如何查找表中的记录。是最重要的一个指标，其性能从高到低依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般来说，得保证查询至少达到range级别，最好能达到ref；否则，就可能会出现性能问题。
| 类型 | 说明 |
|---|---|
| All | 最坏的情况，全表扫描 |
| index | 和全表扫描一样，只是扫描表的时候按照索引次序进行而不是行。主要优点就是避免了排序, 但是开销仍然非常大。如在Extra列看到Using index，说明正在使用覆盖索引，只扫描索引的数据，它比按索引次序全表扫描的开销要小很多 |
| range | 根据索引检查给定范围的行。key 列显示使用了哪个索引，当使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 等操作符，用常量比较关键字列时，可以使用 range |
| ref | 非唯一性索引扫描，返回匹配某个值的所有行。这个类型跟eq_ref不同的是，它用在关联操作只使用了索引的最左前缀，或者索引不是UNIQUE和PRIMARY KEY。ref可以用于使用=或<=>操作符的带索引的列。 |
| eq_ref | 主键或者唯一性索引扫描，最多只返回一条符合条件的记录（高效）。它是除了 const 类型外最好的连接类型 |
| const | 当通过索引检索最多只会有一行匹配的时候，MySQL优化器会在查询前读取它而且只读取一次，因此非常快。当主键放入where子句时，mysql把这个查询转为一个常量（高效） |
| system | 这是const连接类型的一种特例，表中仅有一行数据，相当于系统表。 |
| Null | 意味说mysql能在优化阶段分解查询语句，在执行阶段甚至用不到访问表或索引（高效） |
子查询通过id返回一条数据，故其type为const。而子查询结果集只有一条数据（rows=1），故主查询的type为system。
possible_keys
显示查询可以使用哪些索引，基于查询访问的列和使用的比较操作符来判断。表示他们可以进行高效地查找，但是他们对于后续优化过程可能是没有用的
key 和 key_len
key列显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len列显示MySQL在索引里使用的字节数。如果键是NULL，则长度为NULL。在语义清晰时，长度越短越好 。
ref 和 rows
ref列显示使用哪个列或常数从表中选择行。如下图所示，从 t2 读取数据时，要判断 t2.id = t1.id，所以 ref 就是 mysql.t1.id。
rows列显示MySQL认为它执行查询时必须检查的行数。注意，这是一个预估值。
Extra
Extra是EXPLAIN输出中另外一个很重要的列，该列显示MySQL在查询过程中的一些详细信息，MySQL查询优化器执行查询的过程中对查询计划的重要补充信息。
| 类型 | 说明 |
|---|---|
| Using filesort | MySQL有两种排序算法——通过排序操作或者使用索引，当Extra中出现了Using filesort 说明MySQL使用了后者，但注意虽然叫filesort但并不是说明就是用了文件来进行排序，只要可能排序都是在内存里完成的。大部分情况下利用索引排序更快，所以一般这时也要考虑优化查询了。使用文件完成排序操作，这是可能是ordery by，group by语句的结果，这可能是一个CPU密集型的过程，可以通过选择合适的索引来改进性能，用索引来为查询结果排序。看到这个的时候，查询就需要优化了。 |
| Using temporary | 用临时表保存中间结果，常用于GROUP BY 和 ORDER BY操作中。一般看到它说明查询需要优化了，就算避免不了临时表的使用也要尽量避免硬盘临时表的使用。 |
| Not exists | MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行， 就不再搜索了。 |
| Using index | 说明查询将使用覆盖索引，不需要读取数据文件，从索引树（索引文件）中即可获得信息。如果同时出现using where，表明索引被用来执行索引键值的查找；如果没有using where，表明索引用来读取数据而非执行查找动作。这是MySQL服务层完成的，但无需再回表查询记录。 |
| Using index condition | 这是MySQL 5.6出来的新特性，叫做“索引条件推送”。简单说一点就是MySQL原来在索引上是不能执行如like这样的操作的，但是现在可以了，这样减少了不必要的IO操作，但是只能用在二级索引上。 |
| Using where | 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。注意：Extra列出现Using where表示MySQL服务器将存储引擎返回服务层以后再应用WHERE条件过滤。 |
| Using join buffer | 使用了连接缓存：Block Nested Loop，连接算法是块嵌套循环连接;Batched Key Access，连接算法是批量索引连接 |
| impossible where | where子句的值总是false，不能用来获取任何元组 |
| select tables optimized away | 在没有GROUP BY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。 |
| distinct | 优化distinct操作，在找到第一匹配的元组后即停止搜索更多的行 |
| No tables used | select 语句中使用from dual 或不含任何from子句 |
如此图所示，展示了使用连接缓存和临时表时的Extra信息。
No tables used 示例，执行 explain select now() 也会得到相同的结果。
小结
- EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
- EXPLAIN不考虑各种Cache
- EXPLAIN不能显示MySQL在执行查询时所作的优化工作
- 部分统计信息是估算的，并非精确值
- EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。
以上就是这篇文章的全部内容了，希望本文对大家的学习或者工作具有一定的参考和学习价值；如果有疑问，大家可以在评论区留言交流，也希望大家多多点赞关注。谢谢大家对楼兰的胡杨的支持！