【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条件中的字段来判断是否值得走索引,走索引有的时候不一定会比文件扫描快。