再提SQL Sever存储的问题？

[sundayzhao]

我们编写了一个程序，一段时间后用户的数据库膨胀特别快，经dbcc checkalloc检查，发现一个业务台帐表竟然占用了4万多个数据专用分区，4万多页，可是数据只有6万行，而且这个表的字段并不多。还有这个表是台帐表，只有插入数据和查询数据，不会存在任何的删除和修改操作。我把这个表插入到一个新表，只有几百页。我就奇怪了，SQL Server的空间分配机制是什么，一个区8页，但是4多页竟然用了4万多个专用区，明显利用率极低，而且页的利用率也极低啊，并且奇怪的是本数据库没有任何问题。也能正常使用，就是速度降低的太多。忘了说了，这个表没有主键，但是有一个timestamp字段，是不是这个问题啊。

[pt1314917]

不懂这个，留个标记。期待高手回复。

[dawugui]

是不是有特别的字段?
如ntext , image等.

可尝试收缩数据库.

DBCC SHRINKDATABASE
收缩指定数据库中的数据文件大小。

[fcuandy]

也可能表结构设计的就有问题. 比如字段类型或长度不合适,或冗余太多.

比如.
一个用户表
id name pass phone mail logintimes lastloginip regtime | job address city favorite detail
像这样的表结构, 前面基本都是小字段, 后面有一些稍大点的字段比如 address,favorates,detail等
而后面的这些内容,并不是所有用户都会填的, 最好就是分表.填了,从表就有这个user的记录,没填就没有. 这些都是减少冗余的办法.

个人看法,仅供参考.

[中国风]

1页8K
这样的表一定要建索引，不然查询时会慢...

[中国风]

exec sp_spaceused--查一下表占用的空间。。
由于经常对表insert,update,delete，日志和数据库文件增长，可用收缩日志和数据库文件，
同样也造成了索引的碎片，提高表的效率，应重建表索引或整理索引..

[Limpire]

索引填充因子

[kelph]

你这个业务台帐表是不是写操作非常频繁？

[sundayzhao]

这个表没有主键，也没有建立索引。
结构是
bkdate char(10) not null,bookno timestamp,prodcode char(13) not null,formNO char(14) null,ftype char(1) not null,oprice money ,outoprice money,price money,ccount money,ccost money,coutcost money,ctotal money,ecost money,eoutcost money,etotal money

字段不是很多啊，另外经我研究，dbcc shrinkdatabase 只能压缩未分配的空间，已经分配给表的空间不能压缩。索引填充因子只能对有索引的有效，没有索引的无效。

[yangjiexi]

觉得应该是timestamp的问题，一同期待高手来解决！

[wudan8057]

使用DBCC SHOWCONTIG('TABLENAME')显示表是否存在碎片.如果其中的Scan Density低于90%,考虑整理该表的碎片.

在sqlserver只提供了索引碎片整理DBCC INDEXDEFRAG.表碎片只能用下面的方法:
1、建立新的文件组
2、将表所在文件组修改为新建立的文件组
3、将表所在文件组修改为原理的文件组

[wudan8057]

不知道你有没有建立索引,如果建立了,需要设置索引填充因子.

[sundayzhao]

wudan8057,确实是碎片太多，问题是怎么避免这个问题，怎么能通过程序或者改进sql 语句写法尽量避免此问题。因为我们的客户水平都特别差，而且我们系统走的是产品路线，不可能每个客户都我们自己去解决此问题。

[sundayzhao]

扫描的结果竟然是3.06%，哎，不知道怎么利用率竟然这么低。

[wudan8057]

尝试用下面的方法:
1、如果你的表不是聚集索引，先建立一个聚集索引，并指定索引填充因子。
2、建立个job，每隔一段合适的时间执行DBCC INDEXDEFRAG。

[sundayzhao]

原因没有找到，但是找到可以压缩数据库的方法了。
和wudan8057 的方法差不多，建立一个脚本，逐个表进行重建索引（这个效果好，但是不能同时执行其他操作），如果有聚集索引则重建，没有则创建一个，然后在删除。这样的话，客户一个8G的数据竟然压缩到500多MB，呵呵，效果惊人啊。

今天解贴，不过其实我发这个帖子的目的是找到为什么，哎，看样子大家都没有仔细研究过啊。