整理使用 MySQL 的 explain 语句的用处以及其中中的字段说明，这里使用的是 MySQL 8.0.14 ，MySQL 5.7 之前的内容与之有些不同。
查看 SQL 语句语句的执行计划，方便我们分析 SQL 语句或表结构的性能瓶颈，以及去调优。
下面简单展示 explain 语句： ( jobLevelId 建了索引)
explain select * from employee where jobLevelId = 12;
+----+-------------+----------+------------+------+---------------+-------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+------------+------+---------------+-------+---------+-------+------+----------+-------+
| 1 | SIMPLE | employee | NULL | ref | jobId | jobId | 5 | const | 50 | 100.00 | NULL |
+----+-------------+----------+------------+------+---------------+-------+---------+-------+------+----------+-------+
字段概要说明：
多表联查时，其 id 列表示执行顺序，两条规则：
explain select * from employee e,department d where e.departmentId = d.id and e.jobLevelId = (select id from joblevel where id = 9)
# 为了方便展示 删除了最后两个字段，主要看 id
+----+-------------+----------+------------+--------+--------------------+---------+---------+----------------------+------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows |
+----+-------------+----------+------------+--------+--------------------+---------+---------+----------------------+------+
| 1 | PRIMARY | e | NULL | ref | departmentId,jobId | jobId | 5 | const | 9 |
| 1 | PRIMARY | d | NULL | eq_ref | PRIMARY | PRIMARY | 4 | pmsys.e.departmentId | 1 |
| 2 | SUBQUERY | joblevel | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 |
+----+-------------+----------+------------+--------+--------------------+---------+---------+----------------------+------+
其执行顺序是： joblevel > employee > department
上面的例子展示了其中两种类型，一共有 6 种：
SIMPLE : 简单查询，不包含子查询或Union查询
PRIMARY : 查询中若包含任何复杂的子部分，最外层查询则被标记为主查询
SUBQUERY : 在 select 或 where 中包含的子查询
DERIVED : 在FROM列表中包含的子查询被标记为 DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表中
备注：MySQL5.7+ 进行优化了，增加了derived_merge（派生合并），默认开启，可加快查询效率
explain select * from (select Sname from students where Ssex = ‘男‘) s; # 这里版本是 MySQL 5.1.40, 5.7+ 的显示的是 SIMPLE +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+ | 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 0 | const row not found | | 2 | DERIVED | students | ALL | NULL | NULL | NULL | NULL | 9 | Using where | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+
UNION : 若第二个select出现在uion之后，则被标记为UNION
UNION RESULT : 从UNION表获取结果的select
explain select * from employee where id = 1 union select * from employee where id = 2; +----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+---------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | +----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+---------- | 1 | PRIMARY | employee | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | | 2 | UNION | employee | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | | NULL | UNION RESULT | <union1,2> | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL +----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+----------
当前访问的表的表名，参考以上例子的 table
匹配的分区，详细的没找到，从以上例子看出 5.7 之前没有这个字段
对表访问方式，表示MySQL在表中找到所需行的方式，又称“访问类型”。
//最好到最差
NULL > system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
备注：掌握以下10种常见的即可
NULL > system > const > eq_ref > ref > ref_or_null > index_merge > range > index > ALL
一般到 eq_ref， ref 就行了
指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null）
该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询
key列显示MySQL实际决定使用的键（索引），必然包含在possible_keys中
如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度（key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的）
不损失精确性的情况下，长度越短越好
列与索引的比较，表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
估算出结果集行数，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数
指返回结果的行占需要读到的行 ( rows 列的值)的百分比。按说 filtered 是个非常有用的值，因为对于 join 操作，前一个表的结果集大小直接影响了循环的次数。但是我的环境下测试的结果却是，filtered 的值一直是100%，也就是说失去了意义。
filtered 值只对 index 和 all 的扫描有效（这可以理解，其它场合，通常 rows 值就等于估算的结果集大小。)
性能从好到坏: useing index > usinh where > using temporary | using filesort
该列包含MySQL解决查询的详细信息,有以下部分情况（完整看官方文档）：
Using filesort : 说明MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取，MySQL中无法利用索引完成的排序操作称为“文件排序”
Using temporary : 使用了临时表保存中间结果，MySQL 在对结果排序时使用临时表，常见于排序 order by 和分组查询 group by
Using index : 表示相应的 select 操作中使用了覆盖索引（Covering Index）,避免访问了表的数据行，效率不错！
如果同时出现using where，表明索引被用来执行索引键值的查找
如果没有同时出现using where，表明索引用来读取数据而非执行查找动作
Using where : SQL 使用了 where 条件过滤数据
WHERE 子句用于限制哪些行匹配下一个表或发送给客户端。除非您专门打算从表中获取或检查所有行，那么如果这个 Extra 值不是 Using where，并且 type 是 All 或 index，则查询中可能出现错误。（机翻再修）
Using join buffer : 该值强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进
impossible where : where 子句的值总是 false，不能用来获取任何元组
distinct : 一旦 MySQL 找到了与行相联合匹配的行，就不再搜索了
Select tables optimized away : SELECT 操作已经优化到不能再优化了（ MySQL 根本没有遍历表或索引就返回数据了）
MySQL 8 官方文档 EXPLAIN Output Format 英文
原文：https://www.cnblogs.com/dongjiao/p/14642104.html