MySQL Explain详解

Explain命令用于查看SQL语句的执行计划，展示了mysql如何使用索引来处理select语句以及连接表。

可以帮助选择更好的索引和写出更优化的查询语句。

使用方法，在select语句前加上explain就可以了，如"explain select …;”。

以下以版本’5.7.17-log’为例进行详细讲解，展示信息有12 列，分别是id、select_type、table、partitions、type、possible_keys、key、key_len、ref、rows、filterted、Extra，其中最重要的字段为：id、type、key、rows、Extra。

1 id：选择标识符

这是SELECT的查询序列号，每个id号码，表示一趟独立的查询。一个sql 的查询趟数越少越好，执行顺序分以下三种情况：

id相同：执行顺序由上至下。
id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行。
id有相同也有不同（两种情况同时存在）：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行。

2 select_type：查询的类型

查询中每个select子句的类型， 主要是用于区别普通查询、联合查询、子查询等的复杂查询。

2.1 SIMPLE

简单SELECT，不使用UNION或子查询等。如
explain select * from city。

2.2 PRIMARY

子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY，如多表做UNION的第一个select语句 ，或存在子查询的外层的表 。示例同UNION 等。

2.3 UNION

UNION中的第二个或后面的SELECT语句（多个union就多条记录），不取决于外面的查询，如
explain select code from country where code <1000 union select code from country where code >2000。

2.4 DEPENDENT UNION

UNION中的第二个或后面的SELECT语句，取决于外面的查询（内层的SELECT语句与外层的SELECT语句有依赖关系）， 如
explain select code from country where code in (select 2 from city where code <1000 union select 3 from city where code >2000)。

这里顺带说下MySQL优化器对IN操作符的优化，优化器会将IN中的uncorrelated subquery（与外表不相关子查询）优化成一个correlated subquery（与外表相关子查询），上诉示例会被优化成下面的样子：
explain select code from country c where exists (select 2 from city where code <1000 and code =c.code union select 3 from city where code >2000 and code =c.code)。

2.5 UNION RESULT

UNION的结果，即多个union子语句的集合，id值通常为NULL。示例同UNION 等。

2.6 SUBQUERY

在select 或 where列表中包含了子查询， 子查询中的第一个SELECT，不依赖于外部查询，如
explain select name,(select code from country where code =1000) from country ;

2.7 SUBQUERY DEPENDENT

和SUBQUERY类似，只是结果依赖于外部查询，如
explain select code from country c where exists (select 2 from city where code <1000 and code =c.code）

2.8 DERIVED

低效

用于 from 子句里有子查询的情况。 MySQL 会 递归执行这些子查询, 把结果放在临时表里。 执行这样的子查询是非常低效的，因为扫描基表 t 时没有使用父选择（如id=2）的高选择性条件。 我们从t表中读取太多记录，然后我们必须将它们写入一个临时表并再次读取，然后才能过滤掉它们。

derived_merge

MySQL 5.7开始优化器引入derived_merge，可以理解为Oracle的子查询展开，有优化器参数optimizer_switch='derived_merge=ON’来控制，默认为打开。如下语句不会再出现DERIVED：
explain select * from (select * from city ) t where id=2。

优化语句

derived_merge仍然有很多限制，当派生子查询存在以下操作时该特性无法生效：UNION 、GROUP BY、DISTINCT、LIMIT/OFFSET以及聚合操作，如下语依然会出现DERIVED：
select * from country c left join (select * from city group by name) t on c.name =t.name where t.id=2;
可以改成：
explain select * from country c left join city t on c.name =t.name where t.id=2 group by t.name。

3 table：输出结果集的表

显示这一步所访问数据库中表名称（显示这一行的数据是关于哪张表的），有时不是真实的表名字，也可能是第几步执行的结果的简称，如’’。

4 partitions：匹配的分区

如果查询是基于分区表的话，会显示查询将访问的分区。

5 type：表示表的连接类型

是查询的访问类型，是较为重要的一个指标，表示MySQL在表中找到所需行的方式，又称“访问类型”。

5.1 常用的类型

首先创建一个示例表，

‘CREATE TABLE town (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(30) DEFAULT NULL,
townCode char(4) DEFAULT NULL,
detail varchar(300) DEFAULT NULL,
PRIMARY KEY (id),
UNIQUE KEY uniq_town_code (townCode),
KEY idx_town_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8’

接下来以该表为例进行讲解。

ALL（全表扫描）：Full Table Scan， 将遍历全表以找到匹配的行。如
explain select id,name,detail from town;(注：detail列无索引)
index（覆盖索引）：Full Index Scan，index与ALL区别为index类型只遍历索引树， 一般是使用了覆盖索引或者是利用索引进行了排序分组。如
explain select id,name from city。
range（索引范围扫描）：只检索给定范围的行，使用一个索引来选择行。如
explain select id,name,detail from town where townCode like ‘A%’。
ref（ 非唯一性索引扫描）：使用普通索引或者唯一性索引的部分前缀作为匹配条件或多表连接条件，索引要和某个值相比较，可能会找到多个符合条件的行。如
explain select id,name,townCode from town where townCode =‘ABC’。
eq_ref（ 唯一键联表查询）：类似ref，区别是只能用于多表连接（唯一索引等值匹配时会变成const），并且使用的索引是唯一索引，简单来说，就是只使用primary key或者 unique key作为连接条件，最多只会返回一条符合条件的记录。需要注意的是，多表连接时只能有一个表（数据较少的那一个）应用索引，并且当数据量过少时也不会应用索引（实测少于7个），如
explain select * from town v,town vv where v.id=vv.id。
const（唯一键读取）：和eq_ref类似，都是针对唯一键索引，区别简单地说就是eq_ref用于联表查询的情况，按联表的主键或唯一键联合查询，const是直接按主键或唯一键读取，在查询开始时读取，由于只有一行, 因此该行中列的值可以被优化器的其余部分视为常量。如
explain select * from town where townCode=‘a’。
system（单行表）：system是const类型的特例，当查询的表只有一行的情况下，使用system。如
explain select * from (select count(id) from village) t。
NULL：MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。如
explain select min(id) from town。

5.2 建议

一般来说，得保证查询至少达到range（索引范围查询）级别，最好能达到ref（索引等值查询）。

6 possible_keys：表示查询时，可能使用的索引

指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。这种情况可能是因为表中数据不多，mysql认为索引对此查询帮助不大，如
explain select * from town v,town vv where v.id=vv.id（实测数据量少于7个时）;
也可能是多表连接时只能有一个表用到索引，如
explain select * from town,village where town.id=village.id;
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询。

7 key：表示实际使用的索引

key列显示MySQL实际决定使用的键（索引），必然包含在possible_keys中。

FORCE \USE \IGNORE INDEX：要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。如
EXPLAIN select * from town v,town vv force index(primary) where v.id=vv.id ;

mysql可能并不总会选择合适且效率高的索引去查询，这时适当的force index(indexname) 强制告诉mysql使用什么索引尤为重要。

8 key_len：索引字段的长度

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度， 不损失精确性的情况下，长度越短越好。

8.1 最大可能长度

key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。计算方法如下

8.1.1 类型（基数）

先看索引上字段的类型和长度比如 int=4 ; varchar(20) =20 ; char(20) =20 。
字符串
char(n)：基数n
varchar(n)：基数n
数值类型
tinyint：1字节
smallint：2字节
int：4字节
bigint：8字节
时间类型
date：3字节
timestamp：4字节
datetime：8字节

8.1.2 字符集（乘数）

如果是varchar或者char这种字符串字段，视字符集要乘不同的值，比如utf-8 要乘 3,GBK要乘2。

8.1.3 动态字符串（+2）

varchar这种动态字符串要加2个字节。

8.1.4 是否允许为空（+1）

允许为空的字段要加1个字节 。

8.2 举例

如EXPLAIN select * from village v,town vv force index(idx_town_name)where v.name=vv.name (ken_len=93)。

9 ref：列与索引的比较

表示上述表的连接匹配条件，即哪些列（其它列）或常量被用于查找索引列上的值，常见的有：const（常量），func，NULL，字段名（例：film.id）。如
EXPLAIN select * from village v,town vv force index(idx_town_name)where v.name=vv.name ;(ref=world.v.name)。

10 rows：扫描出的行数(估算的行数)

估算出结果集行数，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数，注意这个不是结果集里的行数。

11 filtered：按表条件过滤的行百分比

使用explain extended时会出现这个列，5.7之后的版本默认就有这个字段，不需要使用explain extended了。这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数。

12 Extra：执行情况的描述和说明

该列显示MySQL在查询过程中的一些详细信息，包含的信息很多，只选择几个重点的介绍下。

Using where（好）：mysql服务器将在存储引擎检索行后再进行过滤。就是先读取整行数据，再按 where 条件进行检查，符合就留下，不符合就丢弃。如
explain select * from town where id>1；

Using temporary（坏）：表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询，常见 group by ， order by。出现这种情况一般是要进行优化的，首先是想到用索引来优化。如
explain select distinct detail from town（注：detail 无索引）;

Using filesort（坏）：MySQL有两种方式可以生成有序的结果，通过排序操作或者使用索引，当query中包含 order by 操作，而且无法利用索引完成的排序操作称为“文件排序”，，但注意虽然叫filesort但并不是说明就是用了文件来进行排序，只要可能排序都是在内存里完成的。大部分情况下利用索引排序更快，所以一般这时也要考虑优化查询了。如
explain select id,name from town order by name（注：如果查询列包含非索引列，还是filesort）;

Using join buffer(坏)：强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进能。如
explain select * from town t left join village v on t.townCode=v.townCode;

Using index（好）：表示相应的select操作中使用了覆盖索引(Covering Index)，避免了回表访问表的数据行，是性能高的表现。如
explain select name from town ；

如果同时出现using where，表明索引被用来执行索引键值的查找，即在查找使用索引的情况下，需要回表去查询所需的数据；如果没有则表明索引只是用来读取数据而非利用索引执行查找。如
explain select name from town where name like ‘a%’（注：如查询列包含name以外的列就不会出现该关键字）;

impossible where （无效）：where子句的值总是false，不能用来获取任何元组。如
explain select * from town where 1=2;

Select tables optimized away（好）：在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作(InnoDB)。如
explain select min(name) from town；

或者对于MyISAM存储引擎优化COUNT()操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。如
explain select count() from town 。