MySQL Explain 执行计划详解

在日常工作中，我们会有时会遇到慢查询——执行时间比较久的SQL语句，我们要解决慢查询的问题需按以下步骤进行：

1. 首先我们必须先找出这些慢查询SQL语句。
2. 然后使用explain这个命令来查看一个这些SQL语句的执行计划。
3. 分析sql的执行计划（查看该SQL语句有没有使用上了索引，有没有做全表扫描以及如何优化）。（QEP：执行计划Query Execution Plan）

mysql> EXPLAIN SELECT * FROM `car`
+----+-------------+---------+------+---------------+------+---------+------+------+-------
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      |   car   | ALL  | NULL          | NULL | NULL    | NULL |    1 | NULL  |
+----+-------------+---------+------+---------------+------+---------+------+------+-------
row in set (0.03 sec)

expain出来的信息有10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段出现的可能进行解释：

一、 id：是SQL执行的顺序的标识,SQL从大到小的执行

1. id列的编号是select的序列号，有几个select就有几个id，并且id的顺序是按select出现的顺序增长的。
2. id值越大执行优先级越高，id相同则从上往下执行，id为NULL最后执行。

二、select_type：是查询中每个select子句的类型，表示对应行是简单还是复杂的查询。

• simple：简单查询,不包含子查询或union等

• primary：复杂查询中最外层的select

• subquery：包含在select中的子查询，不在from子句中

• union：union中的第二个或随后的select语句

•  dependent union：union中的第二个或后面的select语句，取决于外面的查询
• union result：union的结果
• dependent subquery：子查询中的第一个SELECT，取决于外面的查询
• derived：包含在from子句中的子查询。mysql会将结果存放在一个临时表中，也称为派生表（derived的英文含义）
• uncacheable subquery：一个子查询的结果不能被缓存，必须重新评估外链接的第一行

三、table：

这一列表示explain的一行正在访问哪个表。

当from子句中有子查询时，table列是<drivenN>格式，表示当前查询依赖id=N的查询，于是先执行id=N的查询。

当有union时，union result 的table列的值为<union 1,2>，1和2表示参与union的select行id。

四、type：表示MySQL在表中找到所需行的方式，又称“访问类型”。

这一列表示关联类型或访问类型，即mysql决定如何查找表中的行，查找数据化记录的大概范围。

常用的类型有： ALL, index,  range, ref, eq_ref, const, system, NULL

依次从最优到最差分别为：system > const > eq_ref > ref > range > index > ALL。

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

Select_type 说明查询中使用到的索引类型，如果没有用有用到索引则为all

NULL: MySQL能够在优化阶段分解查询语句，在执行阶段用不着访问表或索引。例如：在索引列里中选取最小值，可以单独查找索引来完成，不需要在执行时访问表。

const、system：MySQL能对查询某部分进行优化并将其转成一个常量（可以看show warings的结果），用于primary key或unique key的所有列与常数比较时。所以表最多有一个匹配行，读取一次，速度比较快。system是const类型的特例，表里只有一条元组匹配时为system

eq_ref: primary key或union key索引的所有部分被连接使用，最多只会返回一条符合条件的记录。这可能是const之外最好的联接类型了。简单的select查询不会出现这种type。

ref: 相比eq_ref，不使用唯一的索引，而是使用普通索引或者唯一索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。

range：范围扫描通常出现在in、between、>、<、>=、等操作中。使用一个索引来检索给定范围的行。

index: Full Index Scan，扫描全索引就能拿到结果，一般是扫描某个二级索引，这个扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比all快一点。

all：Full Table Scan， 即全表扫描，扫描你的聚餐索引的所有叶子节点。通常情况下这需要增加索引来进行优化了。

五、possible_keys：这一列显示查询可能使用哪些索引来查找。

explain时可能possible_keys列，而key显示为NULL的情况。这种情况是因为表中数据不多，mysql认为索引对此查询帮助不大，选择了全表查询。
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查where子句看是否可以创建一个适当的索引来提高查询性能，然后用explain查看效果。

六、Key：key列显示MySQL实际采用哪个索引来优化对该表的访问

如果没有使用索引，则该列是NULL。如果想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用force index、use index、或者ignore index。

七、key_len：显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。

举例来说，film_actor的联合索引idx_film_actor_id由film_id和actor_id两个int列组成，并且每个int是4字节。通过结果中的key_len=4可推断出查询使用了第一列：film_id列来执行索引查找。

八、ref：表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值

九、rows： 表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数

十、Extra：该列包含MySQL解决查询的详细信息,有以下几种情况：

Using where:列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤

Using temporary：表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询

Using filesort：MySQL中无法利用索引完成的排序操作称为“文件排序”

(如果出现以上的两种的红色的Using temporary和Using filesort说明效率低)

Using join buffer：改值强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进能。

Impossible where：这个值强调了where语句会导致没有符合条件的行。

Select tables optimized away：这个值意味着仅通过使用索引，优化器可能仅从聚合函数结果中返回一行

 (复合索引再使用时，尽量的考虑查询时，常用的排序方向和字段组合顺序)

mysql> EXPLAIN SELECT * FROM `car` WHERE car_number = '浙A208P5%';
+----+------------+--------+------+--------------+----------+---------+------+------+-------
| id |select_type| table   | type | possible_keys | key     | key_len | ref  | rows | Extra 
+----+-----------+---------+------+--------------+-----------+--------+------+------+------
|  1 | SIMPLE    |   car   |  ref | carNumber     |carNumber |   767  | const|  1   | NULL
+----+-----------+---------+------+---------------+----------+--------+------+------+-----

总结：
• EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
• EXPLAIN不考虑各种Cache
• EXPLAIN不能显示MySQL在执行查询时所作的优化工作
• 部分统计信息是估算的，并非精确值
• EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。