我们经常会使用Explain去查看执行计划，这个众所周知。但我在面试时问面试者，你用Explain主要是看什么？对方的回答大多是“查看是否有使用到索引”，很显然我对这个回答不太满意。
今天我们就来说一说Explain中的“Type”和“Extra”。

一、Explain中的“Type”

Explain中的“Type”

MySQL的官网解释为：连接类型(the join type)。它描述了找到所需数据使用的扫描方式。

最为常见的扫描方式有：

• system：系统表，少量数据，往往不需要进行磁盘IO；
• const：常量连接；
• eq_ref：主键索引(primary key)或者非空唯一索引(unique not null)等值扫描；
• ref：非主键非唯一索引等值扫描；
• range：范围扫描；
• index：索引树扫描；
• ALL：全表扫描(full table scan)；

上面各类扫描方式由快到慢：
system > const > eq_ref > ref > range > index > ALL

1.1 system

扫码类型为system，说明数据已经加载到内存里，不需要进行磁盘IO。
这类扫描是速度最快的。
但是我没有遇到过，遇到了我再来补充！

1.2 const

explain select id from account_user_base where id =1;
const扫描的条件为：
（1）命中主键(primary key)或者唯一(unique)索引；
（2）被连接的部分是一个常量(const)值；

1.3 eq_ref

eq_ref扫描的条件为：对于前表的每一行(row)，后表只有一行被扫描。
我也没有遇到！

1.4 ref

explain select * from account_user_base t1,account_user_security t2 where t1.id = t2.user_id;
对于前表的每一行(row)，后表可能有多于一行的数据被扫描。

1.5 range

explain select * from account_user_base where id > 4;
range类型，它是索引上的范围查询，它会在索引上扫码特定范围内的值。

1.6 index

explain select id from account_user_base;
index类型，需要扫描索引上的全部数据。

1.7 ALL

explain select * from account_user_base;
全表扫描。

1.8总结

• system最快：不进行磁盘IO
• const：PK或者unique上的等值查询
• eq_ref：PK或者unique上的join查询，等值匹配，对于前表的每一行(row)，后表只有一行命中
• ref：非唯一索引，等值匹配，可能有多行命中
• range：索引上的范围扫描，例如：between/in/>
• index：索引上的全集扫描
• ALL最慢：全表扫描(full table scan)

二、Explain中的“Extra”

Explain中的“Extra”

从上图我们得知，Extra的值有NULL、Using index、Using where、Using index condition、Using filesort、Using temporary

2.1 Using where

explain select * from account_user_base where id > 4;
Extra为Using where说明，SQL使用了where条件过滤数据。

2.2 Using index

explain select id from account_user_base;
Extra为Using index说明，SQL所需要返回的所有列数据均在一棵索引树上，而无需访问实际的行记录。

2.3 Using index condition

explain select * from account_user_security t1, account_user_base t2 where t1.user_id = t2.id;
Extra为Using index condition说明，确实命中了索引，但不是所有的列数据都在索引树上，还需要访问实际的行记录。

2.4 Using filesort

explain select id from account_user_base order by nick_name;
Extra为Using filesort说明，得到所需结果集，需要对所有记录进行文件排序。
典型的，在一个没有建立索引的列上进行了order by，就会触发filesort，常见的优化方案是，在order by的列上添加索引，避免每次查询都全量排序。

2.5 Using temporary

explain select nick_name, COUNT(*) from account_user_base GROUP BY nick_name order by nick_name;
Extra为Using temporary说明，需要建立临时表(temporary table)来暂存中间结果。
这类SQL语句性能较低，往往也需要进行优化。
典型的，group by和order by同时存在，且作用于不同的字段时，就会建立临时表，以便计算出最终的结果集。

注：本文大部分内容来自于微信公众号：架构师之路的两篇文章《同一个SQL语句，为啥性能差异咋就这么大呢？（1分钟系列）》、《如何利用工具，迅猛定位低效SQL？ | 1分钟系列》
测试的MySQL版本为InnoDB 5.7.22

我这只是做一个总结，至于为什么会是这样的结果，这个与InnoDB的索引实现有关，里面涉及到“覆盖索引”、“回表”、“最左前缀索引原则”有关，如果对这里面的原理不清楚可以留言问我。