本帖最后由 zoulei2546 于 2012-12-19 19:22:12 编辑

解决方案 »

  1.   

    应该是 第二个查询 因为使用了分区函数而导致 basemoney 索引未能使用。
    具体原因还要分析下执行计划。贴出来看看
      

  2.   

    表 'Worktable'。扫描计数 0,逻辑读取 0 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。看到分区表排序是有这样一个操作,worktable 是SQL优化器在tempdb中生成一个worktable来缓存你的中间查询结果(用来排序),而不用Partition函数没有这个操作,可能是按照这个栏位有排序,所以速度会快。还是按照楼上说的,将执行计划贴出来看一下具体哪里有区别。
      

  3.   

    最右面的部分是什么看不到啊,你不用执行set statistics io on/off,只需要显示查询语句的执行计划就可以了。
      

  4.   

    你的where条件中有自定义函数,这样用不到索引导致全表扫描自然就慢。
      

  5.   

    1、不要用函数查询,虽然结果一样
    2、执行计划被遮住了,应该与函数有关
    3、必要的话,非聚集索引也可以考虑分区
    4、540万数据量,分区效果本来就不会很明显,分区需要在CPU数量较多,内存足够的时候发挥作用,不合适的分区理论上是有可能比不分区慢的
    5、分区函数和分区方案很重要,定位问题没有这个信息只能靠猜,猜错几率总比猜队的大些
      

  6.   

    这里,你的聚集索引在ID列,而你的分区在middleclass列,说明你的表没有建立分区,只是在middleclass列建立了一个分区索引,这样确实不能提高速度法反而下降速度了表分区需要对聚集索引分区
      

  7.   


    这个不一定的,是根据你的WHERE条件建立分区,这样才能充分发挥分区函数的效果
      

  8.   

    因为你的键在ID字段,ID字段没有分区,所以这个查找过程不会因为分区而变快
      

  9.   

    告诉你了,你的表并没有分区,你只不过在为分区的表中增加了一个分区索引而已由于没有聚集,也没有包含必要列,在有排序的查询中并没有使用这个分区索引,使用了排序字段的索引扫描,提示缺少INCLUDE索引怎么修改就不想猜了,谁知道你这几个字段的重复情况,你的分区函数等