这几天测试确认系统的订单大库查询，发现查询很慢，但是都增加了相应的索引，但是依然很慢，查询经常请求超时，涉及的数据库是order-store的order-index表（目前是直接通过和数据库交互的方式去查询的，没有用到搜索引擎）。
经过排查，发现是数据迁移，迁移进来了300多万的数据，拖慢了查询的速度。（图里边的数据被清除了一些，仅作示意）。
1、explain 一下，看下大致的订单总数，而且看到这个查询用到的是type=all，key=null，是全表扫描。
create_date已经加上了索引，为什么查询没有走索引，而是全表扫描呢？
测试的过程中发现了这样的一个现象，查询5月后的订单，用到了idx_create_date索引，
但是查询4月后的订单，就是全表扫描，不会使用idx_create_date索引，严重影响了效率，甚至会拖垮数据库（beta环境机器配置低；是虚拟机，网络可能有问题），导致系统不可用。
经过分析，发现这几天有同事在做数据迁移，很多数据直接被灌入beta环境的数据库，可能是迁移的数据没有能被索引，所以查询的时候，是全表扫描了。
我们又查询了order_index的索引，发现索引数量偏多（对mysql这种千万级的数据库，一般一个表上边的索引都不超过5个）
针对Cardinality（数据散列度，值越大，表明数据越分散，重复的情况少；数越小，代表重复值的值多）
也研究了搜索的条件，例如arrive_time最多只有24个值，因此没必要加索引；即使加了索引，也是走全表扫描，反而会在增加索引的维护成本，降低写入或者更新数据的性能，索引太多，也会占用很大的空间。
因此一些不必要的索引可以去掉。
在这边上线完之后，会进行优化，加入搜索引擎（常用的有sphinx，lucene，solar），这个需要慢慢了解。
