现在数据表里有三千多万数据 因为要统计里面的数据 只要查询就超时。
请问有什么优化的方法吗?里面有些统计:如 select RealName,Sum(CourseClickNum) from ** group by RealName

解决方案 »

  1.   


    如果不是即时要求,LZ可以每天晚上做好汇总,放到一张表里,查询的时候就是显示了。如果是即时的,realname 加索引。如果上述还没有达到想要的效果。
    LZ可能需要考虑升级硬件了。有时候绞尽脑汁,不如老大来一句,那就换台机器来的畅快....
      

  2.   

    select RealName,Sum(CourseClickNum) from ** group by RealName没WHERE 么。这没啥好优化的,在(RealName,CourseClickNum)非聚集索引吧,顶多就索引扫描,减少IO你给的条件太少了
      

  3.   

    可以考慮用視圖索引(IndexedView)即可.比較適合樓主的這個情況.
      

  4.   

    建议:1、你的表结构设计上就有一定的问题,通常超过100万的数据就应该进行表分区操作,可以进行横向表分区和纵上表分区;不建议使用分区表;
    2、你的这个条语句是一个Group by语句,本身就非常耗时;
    3、楼上说的只是对了一点,建立索引是非常有必要的,但你建立的索引没有效果的,因为他的这个条语句是一个全表搜索,索引没有一点用处。
    4、我觉得可以考虑下存储过程,他是效率我就不说了。
      你可以先查出distinct realname.
      然后分别对他进行sum。 
      原则上差不多,但是分别SUM时能使用索引,将你的效率提高数十倍的。
      

  5.   

    1.不宜创建索引的情形
    (1)经常插入,修改和删除的表
    (2)数据量比较小的表,因为查询优化器在搜索索引时所花费的时间可能会大于遍历全表的数据所需要的时间2.适合创建索引的情形
    (1)为where子句中出现的列创建索引
    (2)创建组合索引
    (3)为group by 子句中出现的列创建索引3.聚集索引的设计原则
    (1)该列的数值是唯一的或者很少有重复的记录
    (2)经常使用between ...and..按顺序查询的列
    (3)定义identity的唯一列.
    (4)经常用于对数据进行排序的列.
      

  6.   

    基本就死在group by 上面了、、
    3000W你也敢分组查
    建议你按时间分表吧、、
    近期能快点、、查所有、分表查,页面组
    表结构也可以优化
      

  7.   

    select RealName,Sum(CourseClickNum) from ** group by RealName
    可以建立realname,courseclicknum的組合索引,這樣應該可以形成索引覆蓋
      

  8.   

    这张表是几年之前建的 一共30列 SUM统计的有13列 GROUP BY 分组有5列,现在数据量大了出现问题了才想起优化。
    有WHERE 条件 主要是原SQL脚本弄不出来 上面只是举例
      

  9.   

    目前也是存储过程  你可以先查出distinct realname.   
    然后分别对他进行sum。 
    先查出重复的 在SUM时还得查原表啊???
      

  10.   

    关于realname的数据分布如何,执行计划是并行否?
      

  11.   

    设计分区以提高查询性能
    http://technet.microsoft.com/zh-cn/library/ms177411(SQL.90).aspx