MySQL执行计划分析

执行计划中的常见的列的解释：

type

system/const ：用户主键索引或者唯一索引查询时，只能匹配 1 条数据。一般可以对 sql 查询语句优化成一个常量，那么 type 一般就是 system 或者 const，system 是 const 的一个特例（表中只有一条数据）。

如：explain select * from (select * from film where id = 1) tmp;

eq_ref ：在进行连接查询时，例如 left join 时，如果是使用主键索引或者唯一索引连接查询 ，结果返回一条数据，则 type 的值为一般为 eq_ref。

ref ： 相比较 eq_ref，不使用主键索引或者唯一索引，使用的是普通索引或者唯一索引的部分前缀，索引与一个值进行比较后可能获取到多个符合条件的行，不在是唯一的行了。

range ：通常使用范围查找，例如between，in，<，>，>= 等使用索引进行范围检索。

index ：扫描索引树就能获取到的数据，一般是扫描二级索引，并且不会从根节点扫描，一般直接扫描二级索引的叶子节点，速度比较慢。因为二级索引叶子节点不保存表中其他字段数据 只保存主键，所以二级索引还是比较小的，扫描速度相比 All 还是很快的。

这里用到了覆盖索引，什么是覆盖索引：可以直接遍历索引树就能获取数据叫做覆盖索引。这里遍历 name 索引树就可以获取到主键 id 的值就是覆盖索引。

ALL ：这是一种效率最低的 type，需要扫描主键索引树的叶子节点，获取数据是表中其他列的数据，即全表扫描。

一般来说我们优化到 range 就可以了 最好到 ref

possible_keys

可能用到的key，在优化器生成执行计划之前，优化器会生成多个方案（走哪个索引，全表扫描等），并计算成本（IO成本和CPU成本），这个字段就是记录优化器生成方案的索引，possible_keys越多，那么生成的方案就越多，对性能的消耗就越多，所以该列越少越好。

key

实际用到的索引。

key_len

用到索引的长度，该列可以用来判断我们用了联合索引的多少个列，比如我们有联合索引a，b，c，a和b是varchar（100）并可以为null，c是int不为null，表的字符集为utf-8（一个字符1-3个字节）。

key_len为303：只用到了a
key_len为606：只用到了a，b
key_len为610：只用到了a，b，c
为什么走a是303，多了3，MySQL规定可以为null就多1，可变长就多2，所以是303。

extra

No tables used：查询没有用到表，如 SELECT 1
Impossible WHERE：查询中包含不可能成立的条件，如 1 != 1
Using Index：查询的列全部在二级索引上存在，不需要回表（覆盖索引）。
Using index condition：不需要server进行判断，通过二级索引就可以判断。
Using where：要在server执行的判断。
using join buffer：使用了join buffer来加快连接查询。
using temporary：使用了派生表。
using filesort：不能用索引的B+树进行排序时，ORDER BY会用到内存和磁盘来完成排序。

下面我们用mysql自带的sakila数据库中的表来进行相关的测试

对于payment表，我们看一下它的结构

具体的案例

下面执行第一条查询语句的执行计划

explain select * from payment where payment_id=1;

执行结果如下：

id:自增序号，还可以用来标识驱动表

select_type：查询类型，SIMPLE代表直接对表的简单查询

table：查询的哪一张表

partitions:坐落的分区，分区表一般不用，所以一般这个字段是null

type:索引检索类型，const代表常数(只找到唯一的记录的)查询，效率很高

possible_keys:与当前查询相关的备选索引有哪些，PRIMARY是主键

key:实际使用的索引是哪个

key_len：代表用到的索引值的长度，跟数据类型以及用到了哪些列有关，比如联合索引3个字段，但是只用到了两个列的索引，那这个值的长度就只跟那两个列的数据类型以及是否为空有关。

 ref：现实使用哪个列或常数与key一起从表中选择行。

rows:这条查询语句所扫描的预估行数，可能和最终结果不一致。

filter: 过滤比例，不靠谱的字段

extra:扩展的详细信息

对于MRR的我暂时无法复现，找一个网上的例子：