MYSQL EXPLAIN
| 列名 | 说明 |
|---|---|
| id | 执行编号，标识select所属的行。id值越大优先级越高，越先被执行 |
| select_type | 显示本行是简单或复杂select。如果查询有任何复杂的子查询，则最外层标记为PRIMARY（DERIVED、UNION、UNION RESUlT） |
| table | 显示这一步所访问数据库中表名称 |
| type | 数据访问/读取操作类型（ALL、index、range、ref、eq_ref、const/system、NULL） |
| possible_keys | 示查询时，可能使用的索引 |
| key | 实际使用的索引 |
| key_len | 索引字段的字节数 |
| ref | 列与索引的比较，表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值 |
| rows | 估算出结果集行数，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数 |
| Extra | 额外信息(如Using where，Using temporary)详情见下文 |
select_type
表示查询的类型
| 类型 | 说明 |
|---|---|
| simple | 简单子查询，不包含子查询和union |
| primary | 子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY |
| subquery | 一般子查询中的子查询被标记为subquery，也就是位于select列表中的查询 |
| derived | 派生表——该临时表是从子查询派生出来的，位于form中的子查询 |
| union | 位于union中第二个及其以后的子查询被标记为union，第一个就被标记为primary如果是union位于from中则标记为derived |
| union result | 用来从匿名临时表里检索结果的select被标记为union result |
| dependent union | 顾名思义，首先需要满足UNION的条件，及UNION中第二个以及后面的SELECT语句，同时该语句依赖外部的查询 |
| subquery | 子查询中第一个SELECT语句 |
| dependent subquery | 和DEPENDENT UNION相对UNION一样 |
table
对应行正在访问哪一个表，表名或者别名
- 关联优化器会为查询选择关联顺序，左侧深度优先
- 当from中有子查询的时候，表名是derivedN的形式，N指向子查询，也就是explain结果中的下一列
- 当有union result的时候，表名是union 1,2等的形式，1,2表示参与union的query id
注意：MySQL对待这些表和普通表一样，但是这些“临时表”是没有任何索引的。
type
type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：
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 | 当确定最多只会有一行匹配的时候，MySQL优化器会在查询前读取它而且只读取一次，因此非常快。当主键放入where子句时，mysql把这个查询转为一个常量（高效） |
| system | 这是const连接类型的一种特例，表仅有一行满足条件。 |
| Null | 意味说mysql能在优化阶段分解查询语句，在执行阶段甚至用不到访问表或索引（高效） |
possible_keys
显示查询使用了哪些索引，表示该索引可以进行高效地查找，但是列出来的索引对于后续优化过程可能是没有用的
key
key列显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len
key_len列显示MySQL决定使用的键长度。如果键是NULL，则长度为NULL。使用的索引的长度。在不损失精确性的情况下，长度越短越好 。可参考网上文章key_len大小的计算
ref
ref列显示使用哪个列或常数与key一起从表中选择行。
rows
rows列显示MySQL认为它执行查询时必须检查的行数。注意这是一个预估值。
Extra
| 类型 | 说明 |
|---|---|
| Using filesort | 包含 order by 操作，无法利用索引完成的排序操作称为“文件排序”，大部分情况下利用索引排序更快。 |
| Using temporary | 用临时表保存中间结果，常用于GROUP BY 和 ORDER BY操作，尽量避免临时表的使用，如避免不了，尽量避免硬盘临时表的使用。 |
| Not exists | MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行， 就不再搜索了。 |
| Using index | 说明从索引中查询，不需要读取数据文件，从索引树（索引文件）中即可获得信息。如果同时出现using where，表明索引被用来执行索引键值的查找，没有using where，表明索引用来读取数据而非执行查找动作。 这是MySQL服务层完成的，但无需再回表查询记录。 可参考网上文章Using index 和 Using where;Using index 有什么区别 |
| Using index condition | 索引条件推送，作用在二级索引上。where中包含索引判断，下推至存储引擎判断。具体可参考网上得文章什么是索引下推？ |
| Using where | 通过索引或者表扫描的方式进行where条件的过滤。MySQL服务器将存储引擎返回服务层以后再应用WHERE条件过滤具体可参考网上的文章server层和存储引擎层是如何交互的 |
| Using join buffer | 使用了连接缓存：Block Nested Loop，连接算法是块嵌套循环连接;Batched Key Access，连接算法是批量索引连接 |
| impossible where | 这个值强调了where语句会导致没有符合条件的行（通过收集统计信息不可能存在结果） |
| select tables optimized away | 在没有GROUP BY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。 |
| distinct | 优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作 |
| No tables used | Query语句中使用from dual 或不含任何from子句 |