“工欲善其事，必先利其器”，在日常数据库维护工作中，我们常常需要查看一个SQL在数据库中是如何运行的，例如表的加载顺序、连接关系、以及索引使用情况等。使用EXPLAIN指令可以模拟优化器执行SQL语句、分析查询语句的性能瓶颈，MySQL会返回执行计划信息，但并不实际执行SQL语句。
本文详细解释了EXPLAIN的用法并附以相关示例，希望能帮助大家更深层次地了解MySQL的执行计划。
输出列 | 说明 |
id | 选择标识符 |
select_type | 选择类型 |
table | 输出行的表 |
partitions | 匹配的分区 |
type | 连接类型 |
possible_keys | 可能用到的索引 |
key | 实际用到的索引 |
key_len | 用到索引的长度 |
ref | 列对应的索引 |
rows | 预测要检查的行数 |
filtered | 表条件筛选行的百分比 |
extra | 额外的信息 |
id
id列中的数据为一组数字，表示执行SQL语句或者操作表的顺序，id值相同时，执行顺序由上至下，id列数字越大越先执行，如果数字一样大，那么就从上往下依次执行。这是select请求的序列号，如果引用其他行的结果，这个值可以为null，在这种情况下，table列显示的值类似<union M,N>，表示该行的值在M和N之间。
id相同，从上到下依次执行
子查询，id越大，优先级越高，越先被执行
select_type
类型 | 说明 |
SIMPLE | 简单查询（没有union和子查询） |
PRIMARY | 最外层查询 |
UNION | 第二层，在select之后使用union |
DEPENDENT UNION | union 语句中的第二个select，依赖于外部子查询 |
UNION RESULT | 从一个union返回结果 |
SUBQUERY | 子查询中的第一个select |
DEPENDENT SUBQUERY | 子查询中的第一个select依赖于外部子查询 |
DERIVED | 派生表 select（from子句中的子查询） |
DEPENDENT DERIVED | 派生表 select依赖于另一张表 |
MATERIALIZED | 物化子查询（具体化） |
UNCACHEABLE SUBQUERY | 子查询的结果不能被缓存，必须重新评估每行的外部查询 |
UNCACHEABLE UNION | union中的第二个或后面的select属于UNCACHEABLE SUBQUERY |
SIMPLE：是一个简单查询，不包含子查询或union操作的查询
PRIMARY：查询中如果包含任何子查询，那么最外层的查询则被标记为PRIMARY
SUBQUERY：在SELECT或WHERE列表中包含了子查询，该子查询被标记为SUBQUERY
UNION：Union操作的第二个或是之后的查询值为union；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为DERIVED
UNION RESULT：从UNION表获取结果的查询
DERIVED：出现在FORM子句中的子查询
table
<union M,N>: 由id为M,N查询union操作后参数的结果集，这个结果集其实是一个临时表，指联合查询中id值在M和N之间的行
<derived N>: 这行指出派生表结果集在这行中的id值为N，派生表可能来自from子句中的子查询
<subquery N>: 该行指物化查询在这行的id值为N
partitions
partitions 列代表给定表所使用的分区。在MySQL V5.5和V5.6版本中，只有在EXPLAIN 后面增加分区关键词PARTITIONS时，这列才会显示。未分区的表此列值为空。
type
all：这个就是全表扫描数据文件，然后再在server层进行过滤返回符合要求的记录
index：索引全表扫描，把索引从头到尾扫一遍，常见于使用索引列就可以处理，不需要读取数据文件的查询、可以使用索引排序或者分组的查询
range：索引范围扫描，常见于使用>,<,is null,between ,in ,like等运算符的查询中
ref：不像eq_ref那样要求连接顺序，也没有主键和唯一索引的要求，只要使用相等条件检索时就可能出现，常见与辅助索引的等值查找。或者多列主键、唯一索引中，使用第一个列之外的列作为等值查找也会出现，总之，返回数据不唯一的等值查找就可能出现
eq_ref：出现在要连接过个表的查询计划中，驱动表只返回一行数据，且这行数据是第二个表的主键或者唯一索引，且必须为not null，唯一索引和主键是多列时，只有所有的列都用作比较时才会出现eq_ref
NULL：MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成
const：使用唯一索引或者主键，返回记录一定是1行记录的等值where条件时，通常type是const。其他数据库也叫做唯一索引扫描
system：表中只有一行数据或者是空表，且只能用于myisam和memory表。如果是Innodb引擎表，type列在这个情况通常都是all或者index
fulltext：全文索引检索，要注意，全文索引的优先级很高，若全文索引和普通索引同时存在时，MySQL不管代价，优先选择使用全文索引
ref_or_null：与ref方法类似，只是增加了null值的比较，实际用的不多
unique_subquery：用于where中的in形式子查询，子查询返回不重复值唯一值index_subquery：用于in形式子查询使用到了辅助索引或者in常数列表，子查询可能返回重复值，可以使用索引将子查询去重
index_merge：表示查询使用了两个以上的索引，最后取交集或者并集，常见and ，or的条件使用了不同的索引，官方排序这个在ref_or_null之后，但是实际上由于要读取所个索引，性能可能大部分时间都不如range
possible_keys
key
key_len
key_len显示的值为索引字段的最大可能长度(单位为字节)，可通过该列计算查询中使用的索引的长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。
如果是单列索引，那么整个索引长度会计算进去，如果是多列索引，那么查询不一定都能使用到所有的列，具体使用到多少个列的索引，这里就会计算进去。注意，MySQL的ICP特性（Index Condition Pushdown是MySQL V5.6提供的一种索引优化方式）使用到的索引不会计入其中。另外，key_len只计算where条件用到的索引长度，而排序和分组即使用到了索引，也不会计算到key_len中。
-> explain select amount,name,amount from test1;
-> explain select name from test1;
ref
rows
表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数。rows列显示MySQL查询请求必须检查的行数，对于InnoDB 表, 这个数字是个约数，并不精确。
未添加索引前：
filtered
filtered 列给出了一个百分比的值，这个百分比值和rows列的值结合使用，可以估计出那些将要和执行计划[1] 中的前一个表（指id 列的值比当前表的id 小的表）进行连接的行的数目。这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数。这一列在MySQL 5.7.3之前，只有在EXPLAIN EXTENDED 语句中才会出现，在后续版本扩展输出默认开启，扩展关键词不再必要。
extra
Using where：不用读取表中所有信息，仅通过索引就可以获取所需数据，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示MySQL服务器将在存储引擎检索行后再进行过滤
Using temporary：表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询，常见 group by ; order by
Using filesort：当Query中包含 order by 操作，而且无法利用索引完成的排序操作称为“文件排序”
Impossible where：这个值强调了where语句会导致没有符合条件的行（通过收集统计信息不可能存在结果）
EXPLAIN不会展示关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
EXPLAIN不考虑各种Cache
EXPLAIN不能显示MySQL在执行查询时所作的优化工作
EXPLAIN部分统计信息是估算的，并非精确值
MySQL V5.6.3之前只有 SELECT 可以生成执行计划，V5.6.3及之后的版本SELECT、DELETE、INSERT、REPLACE、UPDATE都可以生成执行计划
EXPLAIN可以使用DESC关键字代替
