对SQL查询语句执行explain命令可以得到SQL语句的执行计划。
id：序号，表示查询中执行select子句或操作表的顺序
-
id相同
上-->下依次执行 -
id不同
id大的优先执行； -
id部分相同
id大的优先执行，id相同的上-->下依次执行
select_type：查询中每个select子句的类型（简单OR复杂）
-
SIMPLE
不包含子查询或者UNION的查询被标记为SIMPLE -
PRIMARY
复杂查询的最外层查询被标记为PRIMARY -
SUBQUERY
在SELECT或WHERE子句中的子查询 -
DERIVED
FROM子句中包含的子查询，该子查询会产生临时表（派生表） -
UNION
出现在UNION之后的SELECT语句会被标记为UNION -
DEPENDENT UNION
UNION之后SELECT语句，同时又依赖外部的查询 -
UNION RESULT
从UNION获取结果的SELECT被标记为UNION RESULT
table：显示查询的表名
partitions：表的分区（MySQL5.7新功能）
type：查询方式（特别重要的一项，关系到查询效率）
查询效率：ALL < index < range < ref < eq_ref < const < system < NULL
- ALL：全表扫描
- index：遍历索引
- range：索引范围扫描
- ref：非唯一索引查找或唯一索引前缀查找
- eq_ref：唯一索引查找
- const：最多只有1条记录匹配
- system：仅有1条记录匹配
- NULL：不用访问表或索引
possible_keys：可能使用的索引
key：实际使用的索引
key_len：索引字节数
ref：被用于索引查找的列或常量
rows：查找记录需要读取的行数
filtered：
Extra：额外信息（重要）
-
Using index
使用了覆盖索引（Covering Index） -
Using temporary
使用了临时表（需要优化） -
Not exists
MYSQL优化了LEFT JOIN，一旦找到了匹配LEFT JOIN标准的行， 就不再搜索了 -
Using where
数据从存储引擎返回后再使用where过滤 -
Using index condition
MySQL原来在索引上是不能执行如like这样的操作的，5.6以后可以了，这样减少了不必要的IO操作，但是只能用在二级索引上 -
Using filesort
无法使用索引排序，单并不是在文件排序，而是尽可能在内存排序（此时也应优化） -
Using join buffer
在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果（需要使用索引来优化） -
Impossible where
where语句会导致没有符合条件的行 -
Select tables optimized away
仅使用索引，优化器可能仅从聚合函数结果中返回一行 -
Index merges
当MySQL 决定要在一个给定的表上使用超过一个索引的时候，就会出现以下格式中的一个，详细说明使用的索引以及合并的类型
Using sort_union(...)
Using union(...)
Using intersect(...)
