1.explain的作用

explain命令可以查看SQL语句的执行计划。当explain于SQL语句一起使用时， MySQL将显示来自优化器的有关语句执行计划的信息。

2.实例

首先创建3张表并插入数据

DROP TABLE IF EXISTS students; CREATE TABLE students ( id INT ( 10 ) UNSIGNED NOT NULL AUTO_INCREMENT, 学号 INT ( 7 ) UNSIGNED NOT NULL, 姓名 VARCHAR ( 20 ) NOT NULL, PRIMARY KEY ( `id` ) ); DROP TABLE IF EXISTS achievement; CREATE TABLE achievement ( id INT ( 10 ) UNSIGNED NOT NULL AUTO_INCREMENT, 课程 VARCHAR ( 20 ) NOT NULL, 学号 INT ( 7 ) UNSIGNED NOT NULL, 分数 INT ( 3 ) NOT NULL, PRIMARY KEY ( `id` ) ); DROP TABLE IF EXISTS studying_student; CREATE TABLE studying_student (   id INT (10) UNSIGNED NOT NULL AUTO_INCREMENT,   学号 INT (7) NOT NULL, PRIMARY KEY (`id`) ) INSERT INTO students ( 学号, 姓名 ) VALUES ( 2016001, '张三' ), ( 2016002, '李四' ), ( 2016003, '王五' ), ( 2016004, '吴六' ); INSERT INTO achievement ( 课程, 学号, 分数 ) VALUES ( '计算机', 2016001, 99 ), ( '计算机', 2016002, 89 ), ( '计算机', 2016003, 79 ), ( '计算机', 2016005, 69 ); INSERT INTO studying_student ( 学号 ) VALUES ( 2016003 ), ( 2016004 ) 

students表中的数据：

studying_student表中的数据：

studying_student表中的数据：

然后执行：

EXPLAIN SELECT * FROM  achievement  WHERE `学号` IN ( SELECT        students.`学号` FROM        students       LEFT JOIN studying_student       ON        students.`学号` = studying_student.`学号` ); 

结果：

id：操作表的顺序

跟据id的值出现的情况不同，操作表的顺序或者执行select字句的顺序也会有所不同

所以上图中的例子先执行查询序号为2，table为students的select语句，然后是查询序号为2，table为studying_student的语句，接着是执行table为achievement和table为 subquery2语句

select_type:查询的类型（来源于Mysql5.7文档）

上图中出现的MATERIALIZED：物化子查询
先了解一下什么是物化子查询

什么是物化策略？

如果子查询执行一次即可以得到结果,即子查询的结果是稳定的,则这样的子查询可以被缓存起来，多次使用。缓存即是物化。缓存到内存中，如果内存中放不下，则会写外存。在MySQL中，这个缓存对应的是临时表（即：物化利用了临时表的机制）。（参考自: MySQL子查询优化—详解–2.）
即上图的两个MATERIALIZED是把查询结果进行了缓存供外部查询使用

table:显示当前的一行数据是关于哪一个表的

如果查询使用了别名，那么这里显示的是别名，如果不涉及对数据表的操作，那么这显示为null，如果显示为尖括号括起来的就表示这个是临时表，后边的N就是执行计划中的id，表示结果来自于这个查询产生。如果是尖括号括起来的<union M,N>，与类似，也是一个临时表，表示这个结果来自于union查询的id为M,N的结果集。如果是尖括号括起来的，这个表示子查询结果被物化，之后子查询结果可以被复用（参考自: Mysql优化之explain详解.）

select_type:

因此上例中的MATERIALIZED意思就是被物化的子查询

type:
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
除了all之外，其他的type都可以使用到索引，除了index_merge之外，其他的type只可以用到一个索引

● If the index is a covering index for the queries and can be used to satisfy all data required from the table, only the index tree is scanned. In this case, the Extracolumn says Using index. An index-only scan usually is faster than ALL because the size of the index usually is smaller than the table data.● A full table scan is performed using reads from the index to look up data rows in index order. Uses index does not appear in the Extra column.

以上说的是索引扫描的两种情况，一种是查询使用了覆盖索引，那么它只需要扫描索引就可以获得数据，这个效率要比全表扫描要快，因为索引通常比数据表小，而且还能避免二次查询。在extra中显示Using index，反之，如果在索引上进行全表扫描，没有Using index的提示。

可以看到上例中的type全部都是all， 原因是字段都没有建立索引（id除外）
我们尝试给学号建立索引，由于学号是唯一的，因此我们可以建立唯一索引

CREATE INDEX stu_num_index ON students (`学号` ASC); CREATE INDEX stu_num_index ON achievement (`学号` ASC); CREATE INDEX stu_num_index ON studying_student (`学号` ASC); 

给三张表的学号列个建立一个唯一索引，继续用上面的explain语句查询
结果：

对比上面没有建立索引的结果：

可以发现查询少了一行， 第三步执行消失，这说明主查询的where语句括号内的执行结果没有被物化。
possible_keys 三行都是新建立的索引stu_num_index。

possible_keys
查询可能使用到的索引都会在这里列出来
可以看到第1、第3行都是我们刚刚给两张表通过学号列建立的索引，
第2行<auto_key>是临时表 subquery2 生成的索引

key
查询真正使用到的索引，select_type为index_merge时，这里可能出现两个以上的索引，其他的select_type这里只会出现一个。

key_len
用于处理查询的索引长度，如果是单列索引，那就整个索引长度算进去，如果是多列索引，那么查询不一定都能使用到所有的列，具体使用到了多少个列的索引，这里就会计算进去，没有使用到的列，这里不会计算进去。留意下这个列的值，算一下你的多列索引总长度就知道有没有使用到所有的列了。要注意，mysql的ICP特性使用到的索引不会计入其中。另外，key_len只计算where条件用到的索引长度，而排序和分组就算用到了索引，也不会计算到key_len中。

ref
如果是使用的常数等值查询，这里会显示const，如果是连接查询，被驱动表的执行计划这里会显示驱动表的关联字段，如果是条件使用了表达式或者函数，或者条件列发生了内部隐式转换，这里可能显示为func

rows
这里是执行计划中估算的扫描行数，不是精确值

extra
对于extra列，官网上有这样一段话：

If you want to make your queries as fast as possible, look out for Extra column values of Using filesort and Using temporary, or, in JSON-formatted EXPLAINoutput, for using_filesort and using_temporary_table properties equal to true.

大概的意思就是说，如果你想要优化你的查询，那就要注意extra辅助信息中的using filesort和using temporary，这两项非常消耗性能，需要注意。

这个列可以显示的信息非常多，有几十种，常用的有：

除了这些之外，还有很多查询数据字典库，执行计划过程中就发现不可能存在结果的一些提示信息

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

（参考自: Mysql优化之explain详解.）