主要是各个参数的含义
id 表示执行顺序,id越大的越先执行
select_type查询的类型,是简单查询还是复杂查询,比如Simple表示简单查询,Primary标识复杂查询中最外层的Select语句的查询,SUBQUERY子查询,就是在select后面的子查询,DRIVED衍生查询,就是from后面的子查询,会先查询出一张衍生表
table 表示当前查询的表
type
NULL 表示在查询优化时就已经确定好数据,不需要搜索表和索引,比如min函数直接在索引就可以拿到结果
system 表示常量级查找,优化器通过优化直接select 常量,而且查找的元祖只有一条记录
const 表示常量级查找,优化器直接select 常量,只有一条数据
ref 表示运用唯一索引查找到唯一一条记录
eq_ref 表示运用索引查找到相关记录
range 表示运用索引进行范围查找
index 表示遍历覆盖索引
ALL 表示遍历聚集索引
possible_key表示可能用到的索引
key 表示实际用到的索引
key_len 表示实际用到的索引字段的长度
ref 表示实际用到的索引字段的类型
rows 表示估计需要扫描的行数
extra 额外信息
Using Index 表示 用到了覆盖索引
Using where 表示 使用了where查找,查询的列未用索引覆盖
Using index condition 表示没用到覆盖索引,是范围查询
Using temporary 表示查询需要创建临时表
Using filesort 表示需要额外排序,如果数据量小时用内存排序,数据量大时需要文件排序,提示需要建立索引优化
Select tables optimized away 表示运用的函数可以直接用到索引,在优化阶段即可确定结果
由explain的使用经验推导出优化原则
1.全值匹配,就是在用联合索引的时候所有的索引字段尽量都用上,是因为这样的话可充分利用索引树,精准定位索引叶子节点,避免多次i/o读取
2.最左前缀法则,就是使用联合索引的时候要按顺序使用联合索引里面的索引字段,因为联合索引是根据索引字段顺序排序了,如果没按顺序使用这些字段,会破坏字段间的有序性,从而无法使用索引搜索
3. 不在索引字段上做操作,比如使用函数之类的,因为这样子无法使用索引,索引上只是对字段的值进行排序,使用函数之后索引字段已经不是原来的值了,所以无法使用索引搜索
4.存储引擎无法使用范围条件后面的列进行索引,因为范围搜索之后剩下的索引树里面的元素中,该列后面的索引字段已经无法维持有序性了,所以无法使用索引搜索
5.尽量使用覆盖索引,是因为为了减少回表操作,直接在二级索引树中就可以得到需要搜索的字段
6.减少使用<>,!=,因为索引树对不等于的搜索无能为力
7.减少使用is null,is not null,原因同上
8.以通配符开头无法使用索引, 因为索引树是按字段的值顺序排序的,值的开头无法确定的话,就相当于无序了,无法使用索引树
9.字符串不加单引号索引失效,这应该是是和mysql的自身的处理有关,不会强制转换类型,类型不匹配直接放弃使用索引
10.少用or和in,因为存储引擎会计算使用or和in时是全表扫描比较方便还是用索引比较方便,如果计算出全表扫描效率更高,就不会走索引, 因此不一定会利用到索引
11.范围查找要注意,原因同上,不过我们可以通过拆分范围来减少搜索数据的大小,从而引导搜索引擎使用索引