要弄一个报表程序， 只查不写， 几百万数据怎么3秒内能统计出数据？（3秒左右最好 尽量不超过10秒）， 每次查出来的数据不大也就1000~2000条， 不过基本都需要全表统计， 各种sum 各种group by 各种order by 各种full join。。。 服务器就一般常见的几万块机子
我现在的思路是在这些大表根据业务情况建立一些汇总表， 比如统计地区销量就： 地区，商品大类， 业务日期，销量， 金额这样， 大概就10w多条， 这样我在这10w多条记录里sum啊group by啊order by啊都比较快，10秒内基本就出来了， 不过有些纠结的是有几个报表是要统计大区里的店铺数， 商品大类里有几个款。。。 尼玛这不是很好搞了
另外就是最科学的建索引、优化查询语句了， 现在主表的主键是订单号varchar（30）， 我换成int会快多少？ 日期加索引， 店号加索引 ， 明细表的索引就2个， 一个订单 一个款号 没设主键。 索引还有什么优化的地方?
另外一个想法是换oracle， 不知道能快多少？ 如果从10秒快到8秒也没意思， 能从10秒到3秒就换。。
我的库情况是这样， 600w的表有3张， 200w的表有10来张， 30w的表有20来张， 这些都是盘点啊销售啊什么的业务表， 都是主从结构， 比如
销售主表： 订单号（varchar 30 主键）， 业务日期（只有天不带小时,每天2000条）， 单据类型（3，4个类型，经常会做where条件）， 店铺表（distinct 1000多条）
销售明细表： 订单号（varchar 30 主键） 商品款号（distinct 8000条）， 颜色（distinct 1w条， 很少统计查询到）、 尺码（distinct 20来条， 很少统计查询到）、 数量、 金额
基础数据表大概20个， 最大最常用的商品档案表8000条， 店铺表1000来条， 其他很多都是小表， 大部分基础数据表都是商品档案的扩展属性， 比如商品大类表， 商品小类表， 商品风格表等，这些都100条以下
------- 大家
10 个解决方案
#1
全表的话索引效率都不高，建议定期汇总保存，查询的时候直接关联汇总表
#2
像这种记流水的数据最好是定期封存，不然会越来越慢。
譬如销售流水，这个需要定期封存的，查的时候去查历史数据就好了。
譬如销售流水，这个需要定期封存的，查的时候去查历史数据就好了。
#3
LZ可以考虑用视图索引(Indexed View),毫秒级的查询速度.
参考 http://www.codeproject.com/Articles/199058/SQL-Server-Indexed-Views-Speed-Up-Your-Select-Quer
参考 http://www.codeproject.com/Articles/199058/SQL-Server-Indexed-Views-Speed-Up-Your-Select-Quer
#4
换了oracle 又能快多少？呵呵，你说的内容已经把你的问题都说出来了，改变处理方式吧，楼上的都说到了
#5
如果希望通过索引来加快速度，而你基本上又都是全表的数据都要查，那么可以考虑建覆盖索引，因为你一个表几十个字段，你不可能在报表中都需要查询，肯定是查询少了的几个字段。
如果访问的字段比较多，那么就考虑做个日结表，或者月结表，每天晚上计算好了存进去，后面直接从里面查询就可以，不用在sum和group by，说白了就是预先把结果存进去，方便以后反复的查询。
另外，在sql server中，索引视图不建议使用，基本上就是摆设，一堆的限制条件。
如果访问的字段比较多，那么就考虑做个日结表，或者月结表，每天晚上计算好了存进去，后面直接从里面查询就可以，不用在sum和group by，说白了就是预先把结果存进去，方便以后反复的查询。
另外，在sql server中，索引视图不建议使用，基本上就是摆设，一堆的限制条件。
#6
查询语句只要够优化的话，效率也会高很多的。
一般来说，在查询的时候尽量去过滤条件。用临时表这些来取得临时结果集，然后再在这个基础上进行查询比较好。
报表统计都可以这样。
一般来说，在查询的时候尽量去过滤条件。用临时表这些来取得临时结果集，然后再在这个基础上进行查询比较好。
报表统计都可以这样。
#7
我们现在就是这样搞的，把经常用到的信息提前汇总好，全表扫描索引用处不大的，另外你可以考虑把要汇总的列放到索引的包含性列里面
#8
不过又说回来，原来的公司，大部分报表是月报，每个月大概700w条数据(原表有超过1.5亿条数据)，建了覆盖索引，基本上10秒内就出来了。
所以，我觉得，只要你的报表不需要每个表中的大部分字段，还会能直接优化的。
因为毕竟，通过建多个日结表，然后写存储过程，把数据存进去，还是有不少工作量的。
所以，我觉得，只要你的报表不需要每个表中的大部分字段，还会能直接优化的。
因为毕竟，通过建多个日结表，然后写存储过程，把数据存进去，还是有不少工作量的。
#9
历史表、索引视图、SSAS都能解决你的问题
#10
定期把报表所需数据计算好，放到另外的表里面，然后报表查这个表显示数据。报表的查询速度就能有保证了。
#1
全表的话索引效率都不高，建议定期汇总保存，查询的时候直接关联汇总表
#2
像这种记流水的数据最好是定期封存，不然会越来越慢。
譬如销售流水，这个需要定期封存的，查的时候去查历史数据就好了。
譬如销售流水，这个需要定期封存的，查的时候去查历史数据就好了。
#3
LZ可以考虑用视图索引(Indexed View),毫秒级的查询速度.
参考 http://www.codeproject.com/Articles/199058/SQL-Server-Indexed-Views-Speed-Up-Your-Select-Quer
参考 http://www.codeproject.com/Articles/199058/SQL-Server-Indexed-Views-Speed-Up-Your-Select-Quer
#4
换了oracle 又能快多少？呵呵，你说的内容已经把你的问题都说出来了，改变处理方式吧，楼上的都说到了
#5
如果希望通过索引来加快速度，而你基本上又都是全表的数据都要查，那么可以考虑建覆盖索引，因为你一个表几十个字段，你不可能在报表中都需要查询，肯定是查询少了的几个字段。
如果访问的字段比较多，那么就考虑做个日结表，或者月结表，每天晚上计算好了存进去，后面直接从里面查询就可以，不用在sum和group by，说白了就是预先把结果存进去，方便以后反复的查询。
另外，在sql server中，索引视图不建议使用，基本上就是摆设，一堆的限制条件。
如果访问的字段比较多，那么就考虑做个日结表，或者月结表，每天晚上计算好了存进去，后面直接从里面查询就可以，不用在sum和group by，说白了就是预先把结果存进去，方便以后反复的查询。
另外，在sql server中，索引视图不建议使用，基本上就是摆设，一堆的限制条件。
#6
查询语句只要够优化的话，效率也会高很多的。
一般来说，在查询的时候尽量去过滤条件。用临时表这些来取得临时结果集，然后再在这个基础上进行查询比较好。
报表统计都可以这样。
一般来说，在查询的时候尽量去过滤条件。用临时表这些来取得临时结果集，然后再在这个基础上进行查询比较好。
报表统计都可以这样。
#7
我们现在就是这样搞的，把经常用到的信息提前汇总好，全表扫描索引用处不大的，另外你可以考虑把要汇总的列放到索引的包含性列里面
#8
不过又说回来，原来的公司，大部分报表是月报，每个月大概700w条数据(原表有超过1.5亿条数据)，建了覆盖索引，基本上10秒内就出来了。
所以，我觉得，只要你的报表不需要每个表中的大部分字段，还会能直接优化的。
因为毕竟，通过建多个日结表，然后写存储过程，把数据存进去，还是有不少工作量的。
所以，我觉得，只要你的报表不需要每个表中的大部分字段，还会能直接优化的。
因为毕竟，通过建多个日结表，然后写存储过程，把数据存进去，还是有不少工作量的。
#9
历史表、索引视图、SSAS都能解决你的问题
#10
定期把报表所需数据计算好，放到另外的表里面，然后报表查这个表显示数据。报表的查询速度就能有保证了。