MySQLexplain之possible_keys、key及key_len详解

MySQLexplain之possible_keys、key及key_len

possible_keys

显示可能应用在这张表中的索引，一个或多个。

查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

key

实际使用的索引。如果为NULL，则没有使用索引

查询中若使用了覆盖索引，则该索引和查询的selet字段重叠，仅出现在key列表中。

覆盖索引：查询的字段与所建索引的字段个数和顺序刚好吻合

key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。

在不损失精确性的情况下，长度越短越好key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的

mysql索引possible_keys，key问题

explain中有两个字段possible_keys，key。

• possible_keys：表示可能用到的索引。
• key：实际使用到的索引。

为什么会有单独的两列？

你的where条件中如果使用到了索引列字段，那么possible_keys会列出索引字段对应的索引。

mysql可能会使用到他， 但是要看实际情况，什么是实际情况？

打个比方，如果你有一个按照日期创建的索引列，每天插入一条数据，插入了一年，那么就有365条数据。

这个时候你的搜索条件是查询昨天的数据，sql类似于：

where create_date  > '昨天' 

explain结果如下：

几个关键点：

• type：range   表示你的sql适合范围查询
• possible_keys：表示mysql可能会用到的索引（也就是create_date字段对应的索引）。
• key：实际用到的索引。
• rows：1   如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的 rows 列就代表预计需要扫描的行数，如果使用索引来执行查询时，执行计划的 rows 列就代表预计扫描的索引记录行数

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

extra：Using index condition; 表示有些搜索条件中虽然出现了索引列，但却不能使用到索引（这个是不是和possible_keys冲突了？有待验证）

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

几个关键点：

• type：all 表示你的sql适合范围查询
• possible_keys：表示mysql可能会用到的索引（也就是create_date字段对应的索引）。
• key：实际用到的索引。
• rows：1041   如果查询优化器决定使用全表扫描的方式对某个表执行查询时，执行计划的 rows 列就代表预计需要扫描的行数，如果使用索引来执行查询时，执行计划的 rows 列就代表预计扫描的索引记录行数

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

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

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

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

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论