150g的表对数据库有什么影响？
这个数据库里，一般的表都不超过2g，以前用这个数据库也挺正常。
但是前阵子，因为一些需求，建了一个汇总的表，四个多月的数据已经达到了150g。
这两天程序运行的有问题，访问数据表（不是150g的那个表）也比以前慢很多很多。
我就忽然想是不是150g的原因。

所以，想问各位，一个这么大的表在数据库放着，对其他的表有没有影响，如果有，有多大的影响？
谢谢了~~~
------解决方案--------------------
我觉得像这么大的数据量用一个表来处理肯定是有问题，得用分表，比如按天，月来建表，同时所谓的汇总的话，你可以采用数据仓库的方式，不同粒度来处理，比如：一天的记录的汇总表，也就每天一条记录，一月的汇总表等等，在提取数据的时候根据不同需求定位需要查询的表这样的话比较合理，同时提取计算的速度加强了，关于，汇总和转表的问题你可以写一个后台程序在固定的时间（比如0：30-1：00）完成，在这个期间停止一切外部的业务处理
------解决方案--------------------
150G的大表对整个数据库有很大影响，理论上来说，SQL一张表超过100万条记录，访问这个张表的效率会下降30%，访问这个数据库效率下降10%
------解决方案--------------------
不过，有办法可以提升效率，重新重建索引。

1.重建数据库索引
SqlServer2005 重建索引 
随着数据的数据量的急剧增加，数据库的性能也会明显的有些缓慢
这个时候你可以考虑下重建索引或是重新组织索引了。
 通过
Sql代码  
1.DBCC SHOWCONTIG('表名')  
DBCC SHOWCONTIG('表名') 可以查看当前表的索引碎片情况，出来的结果大概如下：
  
DBCC SHOWCONTIG 正在扫描 'tblWFProcessRelatedDataInstanceHistory' 表...

表: 'tblWFProcessRelatedDataInstanceHistory' (933630419)；索引 ID: 1，数据库 ID: 8

已执行 TABLE 级别的扫描。

- 扫描页数................................: 727

- 扫描区数..............................: 96

- 区切换次数..............................: 95

- 每个区的平均页数........................: 7.6

- 扫描密度 [最佳计数:实际计数].......: 94.79% [91:96]

- 逻辑扫描碎片 ..................: 3.16%

- 区扫描碎片 ..................: 76.04%

- 每页的平均可用字节数........................: 143.6

- 平均页密度(满).....................: 98.23%

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

其中有些很重要的指标，如扫描密度、扫描碎片等。

最佳计数与实际计数相当时说明索引是比较好的，如相差太多，就必须可以重新建或组织索引。

重建索引命令：

指定表名

Sql代码  
1.DBCC DBREINDEX (tblWFProcessInstance, '',  70)   
DBCC DBREINDEX (tblWFProcessInstance, '',  70)  

 对全库

Sql代码  
1.exec sp_msforeachtable 'DBCC DBREINDEX(''?'')'   

------解决方案--------------------

引用:

引用:我觉得像这么大的数据量用一个表来处理肯定是有问题，得用分表，比如按天，月来建表，同时所谓的汇总的话，你可以采用数据仓库的方式，不同粒度来处理，比如：一天的记录的汇总表，也就每天一条记录，一月的汇总表等等，在提取数据的时候根据不同需求定位需要查询的表这样的话比较合理，同时提取计算的速度加强了，关于，汇总和转表的问题你可以写一个后台程……

如果你九十个表是每天都要操作数据的话，那我就觉得数据库结构设计不合理了，如果你每天都是统计当天的数据，那么你可以把这个统计的数据放一张表，也就是一天一条数据，然后对其他的表转到历史表中，在以后的日子里，如果要查询一个的统计汇总的时候，那么你可以从你的统计的汇总表提取数据
------解决方案--------------------
你可以多看看分区的设计，以及数据仓库的东西，老大有时候也不一定完全正确，真正完全正确的话是不会出现这么大的表的