语句一:
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靠不靠的住……如果靠不住,优化方向在哪……

解决方案 »

  1.   

    看手册。除了MIN和MAX函数外,其他的都不会用到索引!建议建立一个新表,字段为:原来表的主键,原来表数据的聚合结果(比如,SUM()的结果)。
      

  2.   

    带聚类计算的,都不会用到任何索引?貌似也不是这么绝对为GROUP BY使用索引的最重要的前提条件是 所有GROUP BY列引用同一索引的属性,并且索引按顺序保存其关键字(例如,这是B-树索引,而不是HASH索引)。是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引、为该部分指定的条件,以及选择的累积函数。条件比较苛刻而已。但这个依然没有解释为什么走索引的查询比不走索引的查询慢的问题
      

  3.   

    我问题的核心,不在于mysql怎么判断走不走索引我的问题是:explain语句拿来优化,可靠与否。如果可靠,请解释下我给出的实例。
      

  4.   


    根据你这个说法
    那我语句一也不应该走time索引,但explain的确走了索引,现实操作起来看起来也是走了time索引,而且这个索引看来有问题!所以导致查询变慢那么好,我再总结我的问题:
    1、为什么时间范围改动1个小时,就有走索引和不走索引两种情况发生。这种情况mssql也会有,而且我也知道是优化器根据数据量的大小判断是利用索引还是tablescan,我放了7天数据在分区表,我只查1天中的几个小时数据,这种情况mssql利用索引是不会有太多疑义的。mysql判断走索引的机制是什么?
    2、explain,是不是mysql下优化的基本工具,那么这个工具提供给我的信息,是否可靠的帮助我?
      

  5.   

    呵呵。仔细看手册关于GROUP BY 的优化再来问吧。
      

  6.   

    你终于说出了我怀疑的论点……至于guoup by 优化那部分,我都看烂了……还是得不出我试验的结论。罢了,既然explain靠不住,那还有其他方法能从侧面给我优化的方向没?总不至于靠猜吧
      

  7.   

    explain靠不住,那还有其他方法能从侧面给我优化的方向没?总不至于靠猜吧