项目中查询时间断的数据发现查询时间很长。怀疑没有走时间的索引，于是explain一下
EXPLAIN select * from t_order where created_at>'2015-01-01 00:00:00' and created_at<'2017-01-01 00:00:00'
解析：
id：
表示执行的顺序，id的值相同时，执行顺序是从上到下，id的值不同时，id的值越大，优先级越高，越先执行
select_type:
1、SIMPLE表示不包含子查询和union
2、查询中若包含子查询，最外层查询则标记为：PRIMARY
3、在select或者where列表中包含了子查询，则标记为：SUBQUERY
4、在from的子查询会标记为：DERIVED
5、从union selcect出来的结果被标志为：UNION RESULT
type:
表示找到需要行的访问类型
ALL，index，range，ref，eq_ref，const，system，NULL
性能从最差到最好
key:
表示使用哪个索引
从上面的截图看没有走create_at索引。
上网查到资料：
当表的索引被查询，会使用最好的索引，除非优化器使用全表扫描更有效。优化器优化成全表扫描取决与使用最好索引查出来的数据是否超过表的30%的数据。
优化器更加复杂，其估计基于其他因素，列入表的大小，行数和I/O块的大小。
发现原因：
使用count整张表的数据，和条件的数据发现已经超过30%,，所以失效。在建立索引的时候，要根据列基数来建立。列基数=列中不同的数据/除以总数据。越接近1表示
重复数据越少，越适合建立索引。
解决：
根据上面的理论，时间断的范围通过订单号查询。因为订单号可以区分时间，并且列基数=1；