mysql 执行计划explain的列详解和说明

Mysql查询优化器是如何工作的，EXPLAIN的每个输出行提供一个表的相关信息，并且每个行包括下面的列:

列：id: MySQL Query Optimizer选定的执行计划中查询的序列号。表示查询中执行select字句或操作表的顺序，

id值越大优先级越高，越先被执行，id相同，执行顺序由上至下。
列：select_type查询类型：

SIMPLE:简单的select查询，不使用union及子查询

PRIMARY:最外层的select查询

union:union中的第二个或者随后的select查询，不依赖于外部查询的结果集

dependent union:union中的第二个或者随后的select查询，依赖于外部查询的结果集。

subquery: 子查询中的第一个select查询，不依赖于外部查询的结果集

dependent subquery:子查询中的第一个select查询，依赖于外部查询的结果集

derived: 用于from子句里有查询的情况。mysql会递归执行这些子查询，把结果放在临时表里

uncacheable subquery:结果集不能被缓存的子查询，必须重新为外层查询的每一行进行评估

uncacheable union:union中的第二或随后的select查询，属于不可缓存的子查询
列：table：输出行所引用的表
列：type重要的项，显示连接使用的类型：

system:表仅有一行（=系统表）。这是const连接类型的一个特例

const:const用于用常数值比较primary key时，当查询的表仅有一行时，使用System.

eq_ref:const用于用常数比较Primary key时，当查询的表仅有一行时，使用System.

ref:连接不能基于关键字选择单个行，可能查找到多个符合调剂的行，叫做ref是因为索引要跟某个参考值相比较。这个参考值或者是来自一个表里的多表查询的结果集

ref_or_null:如同ref,但是mysql必须在初次查找的结果里找出null条目，然后进行二次查找

index_merge:说明索引合并优化被使用了

unique_subquery:在某些in查询中使用此种类型，而不是常规ref:value in (select primary_key from single_table where some_expr)

index_subquery:在某些in查询中使用此种类型，于unique_subquery类似，但是查询的是非唯一性索引：value in (select key_column from single_table where some_expr)

range:只检索给定范围的行，使用一个索引来选择行，key列显示使用了那个索引，当使用=，<>,>=,<=,is null ，<=>,between 或者IN操作符，用常量比较关键字列时，可以使用range.

index:全表扫描，只是扫描表的时候按照索引次序进行，而不是行，主要优点就是避免了排序，但是开销仍然非常大

all:最坏的情况，从头到尾的全表扫描
列：possible_keys:指出MySql能在该表中使用哪些索引有助于查询，如果为空，说明没有可用的索引
列：key:mysql实际从possible_key选择使用的索引，如果为null,则没有使用索引，很少的情况下，mysql会选择优化不足的索引，这种情况下，可以在select语句中使用use index(indexname)来强制使用一个索引或者使用ignore index(indexname)来强制mysql忽略索引
列：key_len:使用的索引的长度，在不缺失精确性的情况下，长度越短越好
列：ref:显示索引的哪一列被使用了
列：rows:mysql认为必选检查的用来返回请求数据的行数
列：extra：

using filesort:表示MySql会对结果使用一个外部索引排序，而不是从表里按索引次序读到相关内容，可能在内存或者磁盘上进行排序。mysql中无法利用索引完成的排序操作称为'文件排序'