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这些，那么优化器就会使用你这个索引。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。