记一次MySQL不使用索引问题的探究

今天发现一个MySQL的查询，没有使用索引，情况如下：

InnoDB的表，表里的字段：

id，int类型，主键

order，varchar类型

feed_datetime，datetime类型，有索引

其他字段，因为没什么关系就不写了

 

执行的sql如下：

SELECT

         id,order

FROM

         order_table

WHERE

         feed_datetime>= '2017-11-01 00:00:00'

AND feed_datetime <= '2017-11-14 23:59:59';

表中的数据一共3500多万，1号到14号的数据一共360多万，相当于总数据的10%多了一点点，但是这个sql没有使用索引，而是选择了全表扫描，explain之后的结果是这样的：

id	1
select_type	SIMPLE
table	order_table
partitions
type	ALL
possible_keys	inx_feed_datetime
key
key_len
ref
rows	34519257
filtered	27.93
Extra	Using where

后来我缩小了一下日期条件，最后发现查询日期在14天之内时，MySQL就会使用索引，超过14天就不用索引了。

如果我查询14天的记录，并且强制使用该字段的索引：

SELECT

         id,order

FROM

         order_table FORCE INDEX(inx_feed_datetime)

WHERE

         feed_datetime>= '2017-11-01 00:00:00'

AND feed_datetime <= '2017-11-14 23:59:59';

该sql explain后的结果是这样的：

id	1
select_type	SIMPLE
table	order_table
partitions
type	range
possible_keys	inx_feed_datetime
key	inx_feed_datetime
key_len	6
ref
rows	7865646
filtered	100
Extra	Using index condition

看起来效率还可以，至少比全表扫描看起来要好一点，实际上执行效率确实比全表扫描要快，全表扫描要30秒，强制索引要20秒。

至此，产生了两个问题：

1，为什么没有使用索引？

经过不断的调整查询条件中的时间跨度，同时一直强制使用索引，查看该索引效率，最后发现当explain的结果中rows大于全表数据的20%时，mysql就不用索引了。

关于这一点，可能跟mysql查询优化器的一个设置有关，优化器成本模型中的row_evaluate_cost参数，在mysql.server_cost表里，默认是0.2，表示使用索引时扫描的行数大于全表扫描行数的20%时，优化器会考虑放弃使用该索引。

2，为什么explain的结果比实际行数多了一倍还多？

explain中的rows并不是准确值，引用官网中对rows的解释：“rows是MySQL认为要返回准确的数据而需要扫描的行数，并不准确，是一个预估值”，也就是MySQL觉得可能得扫这么多行才能给出最终准确的返回值，然而这句话并没给这个问题多少提示，因为多数情况下这个预估值还是比较接近实际值的。比如对总行数的预估值就比较接近实际行数，在上面的例子中可以看到，全表扫描的预估值是3400多万，表里实际行数是3500多万，只差了一点。

怀疑这个预估值的差异跟索引中B+树的使用逻辑有关，但是还没能确认。