mysql 时间索引失效

项目中查询时间断的数据发现查询时间很长。怀疑没有走时间的索引，因而explain一下性能

EXPLAIN select * from t_order where created_at>'2015-01-01 00:00:00' and created_at<'2017-01-01 00:00:00'
优化

解析：code

id：索引

表示执行的顺序，id的值相同时，执行顺序是从上到下，id的值不一样时，id的值越大，优先级越高，越先执行io

select_type:class

一、SIMPLE表示不包含子查询和unionselect

二、查询中若包含子查询，最外层查询则标记为：PRIMARYnio

三、在select或者where列表中包含了子查询，则标记为：SUBQUERYim

四、在from的子查询会标记为：DERIVED 数据

五、从union selcect出来的结果被标志为：UNION RESULT

type:

表示找到须要行的访问类型

ALL，index，range，ref，eq_ref，const，system，NULL

性能从最差到最好

key:

表示使用哪一个索引

从上面的截图看没有走create_at索引。

上网查到资料：

当表的索引被查询，会使用最好的索引，除非优化器使用全表扫描更有效。优化器优化成全表扫描取决与使用最好索引查出来的数据是否超过表的30%的数据。

优化器更加复杂，其估计基于其余因素，列入表的大小，行数和I/O块的大小。

发现缘由：
使用count整张表的数据，和条件的数据发现已经超过30%,，因此失效。在创建索引的时候，要根据列基数来创建。列基数=列中不一样的数据/除以总数据。越接近1表示

重复数据越少，越适合创建索引。

解决：

根据上面的理论，时间断的范围经过订单号查询。由于订单号能够区分时间，而且列基数=1；