千万级的查询怎么做到最优？？？

现在数据表里有三千多万数据因为要统计里面的数据只要查询就超时。
请问有什么优化的方法吗？

里面有些统计：如 select RealName,Sum(CourseClickNum) from ** group by RealName

作者: zsz1001 发布时间: 2011-11-09

引用楼主 zsz1001 的回复:
现在数据表里有三千多万数据因为要统计里面的数据只要查询就超时。
请问有什么优化的方法吗？

里面有些统计：如 select RealName,Sum(CourseClickNum) from ** group by RealName

如果不是即时要求，LZ可以每天晚上做好汇总，放到一张表里，查询的时候就是显示了。

如果是即时的，realname 加索引。

如果上述还没有达到想要的效果。
LZ可能需要考虑升级硬件了。有时候绞尽脑汁，不如老大来一句，那就换台机器来的畅快....

作者: OrchidCat 发布时间: 2011-11-09

select RealName,Sum(CourseClickNum) from ** group by RealName

没WHERE 么。。。。

这没啥好优化的，在(RealName,CourseClickNum)非聚集索引吧，顶多就索引扫描，减少IO

你给的条件太少了

作者: SQL777 发布时间: 2011-11-09

1、有效数据分区

2、有效关键索引

作者: claro 发布时间: 2011-11-09

可以考慮用視圖索引(IndexedView)即可.

比較適合樓主的這個情況.

作者: ap0405140 发布时间: 2011-11-09

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

作者: zhongguoren666 发布时间: 2011-11-09

引用 5 楼 zhongguoren666 的回复:
建议：1、你的表结构设计上就有一定的问题，通常超过100万的数据就应该进行表分区操作，可以进行横向表分区和纵上表分区；不建议使用分区表；
2、你的这个条语句是一个Group by语句，本身就非常耗时；
3、楼上说的只是对了一点，建立索引是非常有必要的，但你建立的索引没有效果的，因为他的这个条语句是一个全表搜索，索引没有一点用处。
4、我觉得可以考虑下存储过程，他是效率我就不说了。
你可……

作者: fredrickhu 发布时间: 2011-11-09

SQL code

1.不宜创建索引的情形
(1)经常插入，修改和删除的表
(2)数据量比较小的表，因为查询优化器在搜索索引时所花费的时间可能会大于遍历全表的数据所需要的时间

2.适合创建索引的情形
(1)为where子句中出现的列创建索引
(2)创建组合索引
(3)为group by 子句中出现的列创建索引

3.聚集索引的设计原则
(1)该列的数值是唯一的或者很少有重复的记录
(2)经常使用between ...and..按顺序查询的列
(3)定义identity的唯一列.
(4)经常用于对数据进行排序的列.

作者: fredrickhu 发布时间: 2011-11-09

引用 5 楼 zhongguoren666 的回复:
建议：1、你的表结构设计上就有一定的问题，通常超过100万的数据就应该进行表分区操作，可以进行横向表分区和纵上表分区；不建议使用分区表；
2、你的这个条语句是一个Group by语句，本身就非常耗时；
3、楼上说的只是对了一点，建立索引是非常有必要的，但你建立的索引没有效果的，因为他的这个条语句是一个全表搜索，索引没有一点用处。
4、我觉得可以考虑下存储过程，他是效率我就不说了。
你可……

透彻啊

作者: koumingjie 发布时间: 2011-11-09

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

作者: calky 发布时间: 2011-11-09

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

作者: baiynije 发布时间: 2011-11-09

引用 5 楼 zhongguoren666 的回复:
建议：1、你的表结构设计上就有一定的问题，通常超过100万的数据就应该进行表分区操作，可以进行横向表分区和纵上表分区；不建议使用分区表；
2、你的这个条语句是一个Group by语句，本身就非常耗时；
3、楼上说的只是对了一点，建立索引是非常有必要的，但你建立的索引没有效果的，因为他的这个条语句是一个全表搜索，索引没有一点用处。
4、我觉得可以考虑下存储过程，他是效率我就不说了。
你可……

学习

作者: q465897859 发布时间: 2011-11-09

引用 2 楼 sql777 的回复:
select RealName,Sum(CourseClickNum) from ** group by RealName

没WHERE 么。。。。

这没啥好优化的，在(RealName,CourseClickNum)非聚集索引吧，顶多就索引扫描，减少IO

你给的条件太少了

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

作者: zsz1001 发布时间: 2011-11-09

引用 5 楼 zhongguoren666 的回复:
建议：1、你的表结构设计上就有一定的问题，通常超过100万的数据就应该进行表分区操作，可以进行横向表分区和纵上表分区；不建议使用分区表；
2、你的这个条语句是一个Group by语句，本身就非常耗时；
3、楼上说的只是对了一点，建立索引是非常有必要的，但你建立的索引没有效果的，因为他的这个条语句是一个全表搜索，索引没有一点用处。
4、我觉得可以考虑下存储过程，他是效率我就不说了。
你可……

目前也是存储过程

你可以先查出distinct realname.
然后分别对他进行sum。

先查出重复的在SUM时还得查原表啊？？？

作者: zsz1001 发布时间: 2011-11-09

引用 13 楼 zsz1001 的回复:

引用 5 楼 zhongguoren666 的回复:
建议：1、你的表结构设计上就有一定的问题，通常超过100万的数据就应该进行表分区操作，可以进行横向表分区和纵上表分区；不建议使用分区表；
2、你的这个条语句是一个Group by语句，本身就非常耗时；
3、楼上说的只是对了一点，建立索引是非常有必要的，但你建立的索引没有效果的，因为他的这个条语句是一个全表搜索，索引没有一点用处。
4、……

明细的话，只能走原表了。

如果这个表，数据不会更新和删除，仅仅是添加的话，
LZ可以计算一次之后保存一个计算结果表，

再做张记录添加信息的表

每次统计，就统计新添加的数据，算完后，跟原来的计算结果表合在一起即可。

大数据量现在如果对应查询，也是分区，分表，或者统计后出结果表。从明细获取，确实效率不高。

作者: OrchidCat 发布时间: 2011-11-09

引用楼主 zsz1001 的回复:
现在数据表里有三千多万数据因为要统计里面的数据只要查询就超时。
请问有什么优化的方法吗？

里面有些统计：如 select RealName,Sum(CourseClickNum) from ** group by RealName

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

作者: orochi_gao 发布时间: 2011-11-09