我们经常会使用Explain去查看执行计划，这个众所周知。但我在面试时问面试者，你用Explain主要是看什么？对方的回答大多是“查看是否有使用到索引”，很显然我对这个回答不太满意。
今天我们就来说一说Explain中的“Type”和“Extra”。
一、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”
从上图我们得知，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的索引实现有关，里面涉及到“覆盖索引”、“回表”、“最左前缀索引原则”有关，如果对这里面的原理不清楚可以留言问我。
