执行计划中的常见的列的解释:
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的我暂时无法复现,找一个网上的例子: