在平时的工作中，经常会被总监@某某人接口或 sql 性能有问题，需要优化。此时一脸懵逼的我们迅速找到了具体 sql，可怎么分析 sql 的性能呢？从何入手呢？
sql 到底是怎么执行的 用了哪几个索引 有没有全表扫描 查询了多少行记录等等
这个时候，就用到了本文将讲解的 mysql explain 命令，它是查询性能优化不可或缺的一部分。
如图，执行计划包含了 12 个字段：
id、select_type、table、partitions、type、possible_keys、
key、key_len、ref、rows、filtered、Extra
字段 | 说明 |
id | 表示查询中执行 select-子句或者提作表的顺序，id 的值越大,代表优先级高,越先执行 |
select_type | 表示词的类型,伤例如: simple、 pnmary、 subquery 等 |
table | 正在访问的表名,如果有别名,则显示别名 |
partitions | 匹配到的分区信息,如果是非分区表,值为 Null |
type | 查询使用了哪种类型,非常重要的指标,好到差依次为: |
possible_keys | 可能用到的索引,但不确定星否是实际使用到的索引 |
key | 最终实际用到的素引,如果是 Null,则没有用到索引 |
key_len | 用到的索引长度(字节数),短越好 |
ref | 显示索引的哪一列被使用了,可能是一个常数,常见的有: const、func、nul、字段名 |
rows | 大数估算找到所需数据读取了多少的行数,rows 值小越好,直观显示 SQL 性能的好坏 |
filtered | 存储索引的数据在经过过滤后，剩下满足条件的记录数量的比例 |
Extra | 不适台在其他列显示的额外的信息 |
一、id
1、id 相同
id 相同时，sql 顺序执行，由上而下
2、id 不同
如果存在子查询，就会出现 id 的序号递增情况，id 值越大越先执行
3、id 有相同的，也有不同的
id 值大的先执行，红色框先执行，然后是绿色框；相同 id 的，由上而下执行
二、select_type
1、SIMPLE
简单 select 查询，没有子查询、union 交并差集操作
2、PRIMARY
主查询，当查询中包含任何复杂的子部分，最外层的查询就称为主查询 PRIMARY，如这里的 score
3、SUBQUERY
在 where 或 select 中包含子查询，那查询就会称为 SUBQUERY，如这里的 subject 和 teacher
4、DERIVED
在 from 中包含子查询，会被标记为 DERIVED，会把结果放到临时表里，不过 mysql5.7+进行了优化。
5、UNION
union 后面出现 select，那 select 这条查询会标记为 union；如果 union 包含在 from 的子句中，union 前面的 select 会标记为 derived
6、UNION RESULT
意思是从 union 的临时表中获取数据，union1,2 表示用第 1 个和第 2 个的结果进行 union 操作
三、table
表名，并不一定是真实的表名，可能是别名，比如上面的 union1,2
四、partitions
表示命中的分区信息，对于非分区，显示 Null
五、type
查询使用了何种类型，性能好到坏依次是：
Null>systeml>constl>eq_refl>refl>ref_or_nulll>index_mergel>unique_subqueryl>index_subqueryl>rangel>indexl>ALL
常见的几种
NULL>system>const>eq_ref>ref>ref_or_null>index_merge>range>index>ALL
一般来说，查询至少达到 range，最好能到 ref
1、Null
mysql 能够在优化阶段分解查询语句，在执行阶段不用再访问表或索引
2、system
当表仅有一条记录时（系统表），数据量很少，一般不会出现，可以忽略
3、const
表示通过索引一次就能找到，命中 primary key 主键或 unique 唯一索引
4、eq_ref
用于联表查询的情况，按联表的主键或唯一键联合查询
5、ref
非唯一索引，匹配到多行
6、ref_or_null
跟 ref 类型类似，只是增加了 null 值的比较,实际用的不多
7、index_merge
查询使用了两个以上的索引，可能使用索引合并优化的方法，就是说对于多个索引分别条件扫描，然后将各自结果合并（intersect/union），Mysql5.1 开始引入 index_merge.
8、unique_subquery
替换下面的 in 子查询，子查询中的唯一索引，子查询返回不重复的集合
value in (select primary_key from single_table where some_expr)
9、index_subquery
用于非唯一索引，可以返回重复值
value in（select key_column from single_table where some_expr）
10、range
针对一个索引的字段，给定范围检索数据，在 where 语句中使用了：between...and、<、>、<=、in 等条件语句，查询 type 都是 range
11、index
index 和 all 都是读全表，但 index 是遍历索引树，all 是从硬盘读取，所以通常 index 比 all 快,因为索引文件通常比数据文件小，也就是虽然 all 和 index 都是读全表，但 index 是从索引中读取的，而 all 是从硬盘读的
12、all
全表查询
六、possible_keys
可能应用的索引，一个或多个
七、key
查询最终用到的索引，如果为 null，则没有可用索引，如果使用的是覆盖索引（查询的列刚好是索引），则该索引只出现在 key 列
八、key_len
查询用到的索引长度（字节数），越短越好
九、ref 字段
显示索引在哪一列被使用了，如果可能的话，是一个常数
十、rows 字段
以表的统计信息和索引使用情况，估算查询所需的数据要查询多少行
十一、partitions 字段
匹配分区
十二、filtered
存储引擎返回的数据在经过过滤后，剩下满足条件的记录数量的比例
十三、extra
额外重要的信息
1、Using filesort
order by 的字段没有索引，mysql 无法利用索引完成的排序，称为文件排序，这样的 sql 都是需要优化的
2、Using temporary
查询后的结果需要使用临时表来存储，一般在排序或者分组时用到
3、Using index
查询使用了覆盖索引（查询的字段刚好有索引），sql 优化的理想状态
如果同时出现 using where ，说明索引被用来查找
没有同时出现 using where，说明索引只用来读取数据，没有用来查找
4、Using where
查询时没有找到可用的索引，从而通过 where 条件过滤获取结果
5、Using join buffer
连表查询时，连接条件没有用到索引，需要一个连接缓冲区来存储中间结果
6、Impossible where
where 条件，总是 false
7、distinct
一旦 mysql 找到了与行相联合匹配的行，就不在搜索了
8、select tables optimized away
select 操作已经优化到不能再优化了，mysql 没有遍历表或索引就返回数据了
我是臻大虾，希望你能有所收获，咱们下期见。
往期推荐
