​ 在工作中，经常会碰到一些慢查询，Explain可以帮我们更详细的了解MySQL查询的执行计划，用法也很简单Explain 后面跟上SELECT语句即可。执行完之后，会显示一行有多个列的记录，可能很多人和我一样，对EXPLAIN里面字段的含义，并没有深入的去了解过，处于一知半解的状态，只知道一些最常见的。

​ 下面我根据MySQL官方文档，查阅了很多资料，再结合我自己的理解，对EXPLAIN的字段和值做了详细的描述，在总结过程中，也发现了自己的很多知识漏洞，很多时候，总是会想当然的认为，这个就是对的，并没有严密的逻辑验证，大脑喜欢偷懒，正所谓好记性不如烂笔头，写的过程也是对自己知识点掌握程度的批判和考验。

关于EXPLAIN

​ EXPLAIN返回一行记录，通过Explain可以获取到很多信息，如：不同表的查询顺序，查询用了哪些表，能使用哪些索引以及真正用到了哪些索引，用了哪种连接类型，是否有临时表和文件排序等。这些因素对查询的效率有直接的相关，想要使查询更高效，需要对这些条件做一个好的优化。

​ EXPLAIN有12个字段，每个字段对查询优化的权重比不一样，也就是说并不是所有字段都很重要。type,key,Extra字段相对其它字段来说，对查询效率的影响更大，优化查询的时候，先把注意力放到这些字段会比其它字段来得更加直接有效，下面开始具体内容。

EXPLAIN语法

以user_info表为例：

explain select * from `user_info` where uid = 5

结果：

id

select_type

table

partitions

type

possible_keys

key

key_len

ref

rows

filtered

Extra

1

SIMPLE

user_info

NULL

const

PRIMARY

PRIMARY

8

const

1

100.00

NULL

EXPLAIN字段说明

注： 标注星号的字段为重点

id：

SELECT语句的标识符，代表SELECT查询在整个查询中的序号。这个值也可能为NULL，如果这一行是UNION的结果。

select_type:

SELECT查询的类型，该类型的值有11种类型。例如，示例中的值为SIMPLE，表示该查询是一个简单的查询(即：没有子查询和UNION)。

table:

大多数情况下表示输出行所引用的表名，它也可能是下列值之一：

partitions:

只对分区表有意义。意思是查询所匹配到的分区，如果该表为非分区表，则它的值为NULL。

*type:

查询的join类型，注意单表查询也被当做join的特例，并不一定要两张表。连接类型详情下面会详细介绍。

possible_key:

possible_key列是指，在查询中能够被MySQL用到的索引，但在实际情况中，不一定会被全部用到，这取决于MySQL优化器的选择，假设possible_key有A,B,C,3个索引，优化器经过分析认为A索引不需要用，那么实际执行的时候只会用到B,C索引。实际应用中，该列经常帮我们对SQL查询进行优化，如果它的值为NULL，说明没有能被用到的索引，这种情况下，需要调整SQL语句和优化表的索引。

*key:

查询中实际用到的索引，要注意，该列的值可能包含possible_key列中没有出现的索引，当查询满足覆盖索引的条件时，possible_keys列为NULL，索引仅在key列显示，MySQL只需要扫描索引树，不用到实际的数据行检索即可得到结果，查询会更高效，Extra列显示USING INDEX，则证明使用了覆盖索引。 也可以通过FORCE INDEX,USE INDEX或IGNORE INDEX来强制使用或忽略possible_key列中的索引。

覆盖索引概念：

如果索引包含所有满足查询需要的数据的索引成为覆盖索引(Covering Index)。

假设有一个user表，假设索引A包含了col1,col2,col3三个字段，criteria为标准条件。

Query 1:

select * from user where criteria

Query 1使用了索引查询，获取到数据行的主键，但是仍然需要根据主键值扫描实际的数据行。

Query 2:

select `col1`,`col2` where criteria

Query 2中，索引A已经包含了它需的字段，也就是说Query 2不用再去实际的数据行获取数据了，只要扫描完索引树就行了，这样就省了一个步骤，索引树往往比实际的数据表小，所以效率很高，这就是覆盖索引。

key_len:

实际用到的索引字段长度，越短越好。

ref:

ref列显示哪个列或者常数和索引比较筛选出结果。

rows:

rows列表示MySQL认为执行查询必须检查的行数，对Innodb表来说，这是一个预估值，可能并不是确切的值。

filtered:

​ filtered的意思是，首先MySQL利用索引，例如，用range范围扫描出符合的行，如果扫描符合条件的估计值是100行，rows显示估计的值就是100，这一步是存储引擎根据索引筛选后的值，然后在Server层根据其余的WHERE条件过滤。

​ 被过滤器过之后，符合条件的还剩下20行，也就是剩下20%，20%就是filtered中的值。很显然，直接在存储引擎层筛选出20行比先筛选出100行再过滤要更好，通常情况下，filtered的值越大可能意味着索引越好。

​ 另一方面看，你也可以完全忽略filtered，因为这个值在大多数情况下只是一个不准确的估计，应该把注意力放到优化其它更有用的字段上，尤其是type,key,Extra。例如：尽量避免filesort排序，使用索引排序。或者有一个更好的type值，对性能的提升是非常巨大的，这种情况，即使filtered的值低也没关系。假设一个查询A， type=all,filtered=0.1%。那么首要先关注type字段，可通过添加索引来优化，可以先不管filtered。

​ 所以对这个值不需要太认真，即使100%也不意味着索引一定好，反过来也不一定说明索引差，type比它更能说明索引的好坏。

*Extra:

这个列包含Mysql解决查询的详细信息，详情见下方。

EXPLAIN字段值说明：

select_type:

select_type 值

描述

SIMPLE

简单的SELECT查询(没有UNION和子查询)

PRIMARY

一个需要union操作或者含有子查询的select，位于最外层的单位查询的select_type即为primary。且只有一个

UNION

UNION连接的select查询，除了第一个表外，第二个及以后的表select_type都是union

DEPENDENT UNION

与union一样，出现在union 或union all语句中，但是这个查询要受到外部查询的影响

UNION RESULT

UNION之后的结果集

SUBQUERY

除了from字句中包含的子查询外，其他地方出现的子查询都可能是subquery

DEPENDENT SUBQUERY

与dependent union类似，表示这个subquery的查询要受到外部表查询的影响

DERIVED

FROM字句中出现的子查询。语法：SELECT ... FROM (subquery) [AS] tbl_name ...

MATERIALIZED

被物化的子查询

UNCACHEABLE SUBQUERY

对于外层的主表，子查询不可被物化，每次都需要计算(耗时操作)

UNCACHEABLE UNION

UNION操作中，内层的不可被物化的子查询(类似于UNCACHEABLE SUBQUERY)

通过 **物化 ** 优化子查询的原理：

​ 优化器使用物化的方式能让子查询更高效的执行，类似缓存技术，把第一次查询的结果存起来，避免多次的耗时操作，同时也有它自身的限制，不是所有子查询都能被物化的。物化技术把子查询产生的结果放在一个临时表中，如果数据量小的话，通常是在内存中完成，数据大的时候就降级到磁盘进行，速度也会慢很多。首先，MySQL得到子查询的结果，然后把结果放到临时表中，在随后的任何时间，当需要这个结果时，MySQ就再次引用这个临时表，不需要再执行计算了。优化器可能会使用哈希索引(复杂度为O(1)，很快)来快速且低成本的查找表，这个索引是唯一的，避免了重复，能使表更小。

SELECT * FROM t1

WHERE t1.a IN (SELECT t2.b FROM t2 WHERE where_condition);

type(连接类型)：

system

当表只有一行数据的时候，这是const连接类型的特例。

const

表中最多只有一行匹配，在查询开始时被读取。因为只有一行，该行中列的值可以被优化器的其余部分视为常量。const表非常快，因为他们仅被读取一次。将PRIMARY KEY 或 UNIQUE INDEX索引和常量值比较时,会使用const。例如：

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name

WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref

假设A JOIN B，B表读取A表的各个行组合的一行时，通过B表的PRIMARY KEY或UNIQUE NOT NULL索引列连接时，优化器会使用eq_ref类型，这是除了system和const之外最快的JOIN类型。

举例说明：

表tableA,有(id,text)字段，id为PRIMARY KEY,A表数据为：

id

text

1

HELLO

2

THANK

表tableB有(id,text)字段，id为PRIMARY KEY,B表数据为：

id

text

1

WORLD

2

YOU

现在通过JOIN将两个表关联起来

SELECT A.text,B.text

FROM tableA AS A,tableB as B

WHERE A.id=B.id

这个连表查询是非常快的，因为在A表中扫描的每一行，在B表中也仅一行满足条件。

ref

​ A JOIN C时，A表中的每一行不是唯一的，对单表查询也一样，有多个满足条件的行，查询的KEY是单个索引或复合索引的最左前缀(不是唯一索引和主键)，也就是说C表的id是一个非唯一索引。这种情况下，优化器会使用ref优化，如果只有少部分行(rows)满足条件，这个连接类型(join type)是很好的。ref用于索引的比较操作，注意：仅对于=,<=> 操作有效，对于>,

举例说明：

现在有tableC，id为索引，不唯一。数据为：

id (非唯一索引)

text

1

HANGZHOU

1

SHANGHAI

现在通过LEFT JOIN将A和C关联起来:

SELECT A.text,C.text

FROM `tableA` AS A

LEFT JOIN `tableC` AS C ON A.id=C.id

这个JOIN不像之前的那么快，因为在表A中扫描的每一行，在表C中可能有很多行满足条件，C的id不是唯一索引。

fulltext

使用了全文索引，Innodb不支持全文索引。

ref_or_null

如果一个查询的WHERE子句中包含colA IS NULL的条件，但是colA已经被声明为NOT NULL，此时优化器会使用ref_or_null类型。

SELECT * FROM ref_table

WHERE key_column=expr OR key_column IS NULL;

index_merge

​ 在MYSQL5.0之前是没有索引合并功能的，假设A表有3个单独的索引col1 ,col2,col3，然后执行如下SQL:

SELECT * FROM A WHERE col1=1 AND col2=2 AND col3=3

实际查询中只有一个索引能被用到，这种情况，只能通过建立复合索引(col1,col2,col3)才能在索引中用到所有字段。

​ 5.0之后有了索引合并，当检索数据行时出现多个范围扫描条件时，在满足索引合并前提条件时(单个索引覆盖WHERE条件的字段)，MySQL优化器可能会使用索引合并(不一定)，首先分别对多个索引进行扫描，然后合并来自单个表的扫描结果，它不能合并多个表的扫描结果，合并的方式有3种：

unions：索引取并集

intersections：索引取交集

Sort-Union:先对取出的数据按主键排序，再取并集

索引合并条件：

WHERE子句中的范围条件，WHERE中出现字段必须被索引覆盖，如果colA没添加索引，则只会对colB和colC进行索引合并，Extra字段显示Using intersect(colB,colC);，type为index_merge，则说明用到了索引合并。

WHERE colA = const1 AND colB = const2 AND colC = const3

Innodb表中的主键的任何范围条件，>,等。

SELECT * FROM innodb_table

WHERE primary_key < 10 AND key_col1 = 20;

​ 满足了条件，MYSQL会选择索引行数最少的字段对索引结果进行合并，最终使用哪个索引字段来合并也不一定，也可能不使用合并，这取决于优化器，如果优化器认为没必要使用索引合并优化，就会使用其它优化，也许会选择type 为range或更高效的ref的优化。

​ 当优化器决定使用索引合并优化，如果WHERE条件用AND连接，优化器会使用INTERSECTIONS合并算法，对多个索引扫描的结果取交集。如果用OR连接，优化器会选择UNIONS或SORT-UNIONS合并算法，对多个索引扫描的结果取合集，SORT-UNIONS和UNIONS的主要区别是，前者在扫描完数据时，需要先对数据按主键排序，再取它们的合集。

​ 在WHERE子句中使用AND时，使用复合索引比索引合并更高效，因为复合索引只用一个索引筛选，没有匹配合并的过程，这个过程节省了很多时间。

​ 在使用OR时，复合索引是不起作用的，这种情况下，使用UNIONS索引合并效果更好。如果不想使用某种索引合并，也可以选择关闭。可通过optimzer_switch系统变量查看各个索引合并的开启状况。如下：

SELECT @@optimizer_switch

索引合并算法的默认都是开启的，可以通过关闭某个合并算法。例如：

SET optimizer_switch = 'index_merge_intersection=off'

unique_subquery

这种类型是eq_ref类型在子查询中的替代类型。例如

SELECT * FROM A WHERE

value IN (SELECT id FROM B WHERE some_expr)

B表中的id在A表中有唯一对应的记录。

range

​ 在WHERE子句中，执行>,,=,BETWEEN,IN() 等操作时，MySQL可能会(不一定)使用range类型，Explain中key列的值就是实际用到的索引，key_len是它们中最长的索引的长度。如果优化器认为使用索引筛选没有全表扫描来得及，例如：条件筛选后的行占全表的50%以上，即使有索引可用，优化器也会选择全表扫描，即type=ALL。

​ 为什么呢？解释这个问题之前，需要先了解几个概念。对Innodb表来说，每个表都有一个聚簇索引，InnoDB的聚簇索引实际上在同一个结构中保存了B-Tree索引和数据行信息。因为无法把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。二级索引存储的是记录的主键，而不是数据存储的地址，索引数据和存储数据是分离的，唯一索引、普通索引、前缀索引等都是二级索引。实际上，InnoDB在查询任何数据时，最后都是通过主键来查询的。首先我们根据索引条件在索引树上扫描出对应的主键值。然后根据这个值去聚簇索引总超找到对应的行(如果是覆盖索引则省略这一步)。

​ 在某些情况下，索引条件扫描出的数据行非常大，可能占了全表的50%，此时再根据主键找到对应的数据块是不划算。主键的BTree查找属于文件的随机搜索，但是如果随机搜索文件数据的目的是为了查找一半的数据，这并不是最优化的，只要对数据文件进行大量的顺序读写要更快，这种情况下，索引会被忽略。

index

​ index类型和ALL类型几乎相同。有两种情况：

若SELECT中列全部被索引覆盖，所需要的数据可以直接在索引中读取，MySQL只需对索引树进行扫描，这通常比扫描实际数据行要快，因为索引树通常比数据表更小，这种情况下，Extran的值会显示USING INDEX。

使用索引中读取的主键值，按索引顺序对全表进行扫描，此时Extra中没有USING INDEX。

ALL

对表的每一行进行扫描，这是最糟糕的情况。一般，你可以通过添加索引来避免这种情况发生。

Extra列值的含义:

​ Extra列包含了MySQL处理查询的一些额外信息，下面的列出了Extra中可能出现的值，如果你想让查询尽可能的快，应该注意下Extra字段中是否出现了using filesort 和using temporary。下面只列除了在实际应用中经常会出现，相对比较重要的一部分，若描述的不够详细，可查看MySQL官方文档。

const row not found

SELECT * FROM A

如果A表为空，则会出现改值。

DISTINCT

mysql在寻找不同的值，当它找到第一个匹配的行之后，就停止搜索更多的行了。例子：

no matching row in const table

用唯一索引或者主键查询时，没有匹配到的数据。

Not exists

MySQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了，。例如：

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id

WHERE t2.id IS NULL;

Using filesort

​ 这个值表示，MySQL必须对检索到的结果进行额外的排序。排序是按照连接类型遍历所有行并存储排序键和指向行的指针，以匹配满足where子句条件的所有行，然后对键进行排序，并按排序顺序检索行。根据不同情况，MySQL会选择不同的排序算法，在数据比较小的时候，MySQL会利用排序缓冲区作为优先级队列将结果在内存中排序，否则只能通过合并文件的方式合并，那会慢很多，排序缓冲区的大小取决于sort_buffer_size变量的大小。

​ 总之，当看到filesort的时候就应该引起重视，通过优化索引来避免额外的文件排序，这对性能影响是很大的。

Using index

单个索引覆盖了SELECT的所有列(即：覆盖索引)，不需要对实际的数据行进行扫描。

Using index condition

​ Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式。当关闭ICP时,index 仅仅是data access 的一种访问方式，存储引擎通过索引回表获取的数据会传递到MySQL Server 层进行where条件过滤。

​ 当打开ICP时,如果部分where条件能使用索引中的字段,MySQL Server 会把这部分下推到引擎层,可以利用index过滤的where条件在存储引擎层进行数据过滤,而非将所有通过index access的结果传递到MySQL server层进行where过滤.

优化效果:ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数,减少io次数，提高查询语句性能。

Using index for group-by

和USING INDEX很相似，区别是，当查询语句中含有DISTINCT和GROUP BY操作时，仅需访问索引树，不需要访问实际的表时，使用该优化。

``Using sort_union(...),Using union(...),Using intersect(...)`

当查询产生索引合并时会显示该值，type为index_merge。

Using temporary

为了处理查询，MySQL必须建立一个临时表才能产生结果。典型的情况是，在使用GROUP BY和ORDER BY子句时，两者使用了不同的列会导致产生临时表。

Using where

using where 是指使用WHERE或ON子句，MySQL Server层收到存储引擎返回的结果时，需要对结果再次过滤，不需要返回所有结果，注意LIMIT不算限制条款。如果没有用到索引using where只是说明，使用了顾虑条件过滤。

参考