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这些，那么优化器就会使用你这个索引。