explain中有两个字段possible_keys,key。

possible_keys:表示可能用到的索引。

key:实际使用到的索引。

为什么会有单独的两列?

你的where条件中如果使用到了索引列字段,那么possible_keys会列出索引字段对应的索引。mysql可能会使用到他, 但是要看实际情况,什么是实际情况?

打个比方,如果你有一个按照日期创建的索引列,每天插入一条数据,插入了一年,那么就有365条数据。这个时候你的搜索条件是查询昨天的数据,sql类似于:

where create_date  > '昨天' 

explain结果如下:

mysql索引possible_keys,key问题。-LMLPHP

几个关键点:

type:range   表示你的sql适合范围查询

possible_keys:表示mysql可能会用到的索引(也就是create_date字段对应的索引)。

key:实际用到的索引。

rows:1   如果查询优化器决定使用全表扫描的方式对某个表执行查询时,执行计划的 rows 列就代表预计需要扫描的行
数,如果使用索引来执行查询时,执行计划的 rows 列就代表预计扫描的索引记录行数

因为我们只查昨天的,一天一条数据,所以这里是1。

extra:Using index condition; 表示有些搜索条件中虽然出现了索引列,但却不能使用到索引(这个是不是和possible_keys冲突了?有待验证)

然后我们换一个查询方式,查昨天之前的364天的数据,sql类似如下:

mysql索引possible_keys,key问题。-LMLPHP

 

几个关键点:

type:all 表示你的sql适合范围查询

possible_keys:表示mysql可能会用到的索引(也就是create_date字段对应的索引)。

key:实际用到的索引。

rows:1041   如果查询优化器决定使用全表扫描的方式对某个表执行查询时,执行计划的 rows 列就代表预计需要扫描的行
数,如果使用索引来执行查询时,执行计划的 rows 列就代表预计扫描的索引记录行数

因为我们只查昨天之前的,所以数据量是1041条。

好了,得出的结论就是possible_keys会列出你的where条件中可能会使用到的索引列,但是具体用不到这个索引,是需要根据你的实际情况来的,如果你的条件,使用到索引和不使用到索引所消耗的效果差不错(磁盘io,数据读取等)。

举例来说就是上面的例子,一个条件查询了表中的百分之99的数据,即使你的where条件中使用到了索引(并且使用了正确使用索引的姿势。),那么优化器也会选择放弃使用这个索引,因为你使用了这个索引,还会额外带来回表的代码,那么还不如直接全表扫描。

那么他就会直接放弃使用这个索引,直接进行全表扫描。反之,如果你的数据查询确实是非常的减少磁盘io这些,那么优化器就会使用你这个索引。

06-07 13:19