【mysql】记一次优化多个索引的过程

一、数据库中的铺地数据100W，

二、使用到的where条件

三、优化历程

 索引的选择，因为含有order by，所以后面的字段必须要加到索引里面，查询效果：

第一种方式，ALTER  TABLE  table_name  ADD  INDEX  SLP_T_TTKD_ORDER_INDEX9(ZEX_ID,ORDER_TIME);,explain不走文件扫描，查询结果如下，执行耗时1.4S，不是很理想

第二种方式，ALTER  TABLE  table_name ADD  INDEX  SLP_T_TTKD_ORDER_INDEX9(ZEX_ID,CUST_ACCOUNT,ORDER_TIME); ，explain和查询的结果跟第一种方式差不多，不理想。

第三种方式，在上面的索引基础上面新增PRINT_COUNT的字段，ALTER  TABLE  table_name ADD  INDEX  SLP_T_TTKD_ORDER_INDEX9(ZEX_ID,CUST_ACCOUNT,PRINT_COUNT,ORDER_TIME); explain走文件扫描，查询效率应该不是很高，但是查询耗时只用了2ms，速度很快，

为什么呢？加了PRINT_COUNT字段就很快呢，我看一下PRINT_COUNT这个字段的数据都是0，于是我here条件中PRINT_COUNT > 0 替换成 PRINT_COUNT >= 0，出现了下面的情况

第四种情况，我把where条件中PRINT_COUNT > 0 替换成 PRINT_COUNT >= 0，索引选择了其他索引，查询速度也是很慢。

第五种情况：根据上面的结果，我新增了两个组合字段索引。ALTER  TABLE  table_name  ADD  INDEX  SLP_T_TTKD_ORDER_INDEX9(ZEX_ID,CUST_ACCOUNT,ORDER_TIME);
ALTER  TABLE  table_name  ADD  INDEX  SLP_T_TTKD_ORDER_INDEX10(ZEX_ID,CUST_ACCOUNT,PRINT_COUNT,ORDER_TIME);
其中PRINT_COUNT>0的执行效果如下，explain走文件扫描，执行效果很好

另一个PRINT_COUNT>=0的执行效果如下，explain走index9这个索引，执行效果比较好

总结，mysql优化器，在选择索引的时候会根据where条件中的字段来判断是否值得走索引，走索引有的时候不一定会比文件扫描快。