语句一:
explain select cellid,sum(dltraffic) from test where time >= '2008-09-19 02:00:00' and time< '2008-09-19 09:00:00' group by cellidSIMPLE test range Time Time 8 558770 Using where; Using temporary; Using filesort语句二:
explain select cellid,sum(dltraffic) from test where time >= '2008-09-19 02:00:00' and time< '2008-09-19 10:00:00' group by cellidSIMPLE test ALL Time 23899705 Using where; Using temporary; Using filesort相当费解阿……只不过结束时间增加了1个小时,索引就用不上了?执行结果更加匪夷所思……
语句一执行耗时:3500ms (才扫描558770行阿)
语句二执行耗时:1859ms (显示的是全表扫描……)利用索引的比不利用索引的慢……
当然,可以解释为我这个索引做的不好。可我一下还没想到怎么不好了……
后来我把索引删除了
语句一执行耗时:1765ms 正常了……另外,我这个表是按time做按天range分区的。不知道这个有没有什么影响?其实,我最关心的是这个explain靠不靠的住……如果靠不住,优化方向在哪……
explain select cellid,sum(dltraffic) from test where time >= '2008-09-19 02:00:00' and time< '2008-09-19 09:00:00' group by cellidSIMPLE test range Time Time 8 558770 Using where; Using temporary; Using filesort语句二:
explain select cellid,sum(dltraffic) from test where time >= '2008-09-19 02:00:00' and time< '2008-09-19 10:00:00' group by cellidSIMPLE test ALL Time 23899705 Using where; Using temporary; Using filesort相当费解阿……只不过结束时间增加了1个小时,索引就用不上了?执行结果更加匪夷所思……
语句一执行耗时:3500ms (才扫描558770行阿)
语句二执行耗时:1859ms (显示的是全表扫描……)利用索引的比不利用索引的慢……
当然,可以解释为我这个索引做的不好。可我一下还没想到怎么不好了……
后来我把索引删除了
语句一执行耗时:1765ms 正常了……另外,我这个表是按time做按天range分区的。不知道这个有没有什么影响?其实,我最关心的是这个explain靠不靠的住……如果靠不住,优化方向在哪……
根据你这个说法
那我语句一也不应该走time索引,但explain的确走了索引,现实操作起来看起来也是走了time索引,而且这个索引看来有问题!所以导致查询变慢那么好,我再总结我的问题:
1、为什么时间范围改动1个小时,就有走索引和不走索引两种情况发生。这种情况mssql也会有,而且我也知道是优化器根据数据量的大小判断是利用索引还是tablescan,我放了7天数据在分区表,我只查1天中的几个小时数据,这种情况mssql利用索引是不会有太多疑义的。mysql判断走索引的机制是什么?
2、explain,是不是mysql下优化的基本工具,那么这个工具提供给我的信息,是否可靠的帮助我?