SQL中减小的行大小并没有减小表的大小

有人可以解释我在SQL Server 2005中看到的一些行为吗？SQL中减小的行大小并没有减小表的大小

我一直负责减小尺寸或我们的数据库。

该表包含将近600万条记录，并且我计算出行大小为1990字节。我拿了一张表的副本，并通过各种技术将行大小减小到803字节。

当我比较原始表的数据大小（右键单击属性或sp_spaceused）与新表，我看到节省只有21.7 MB。这远不及我所期待的。

这里是我怎样计算出来的行大小：如果柱是数字/十进制然后我用MSDN大小（http://msdn.microsoft.com/en-us/library/ms187746.aspx），对于我使用syscolumns.length的所有其他内容。如果列是可空的，我添加了一个额外的字节。

以下是我实施的一些更改。

原来不必要nvarchars为VARCHAR处理
制造列为NOT NULL
减少VARCHAR列的最大长度，以适应实际数据
删除一些不使用的列
夫妇日期时间到SMALLDATETIME
转身一些小数到整数。
将16个可为空的BIT列合并到一个位掩码int中。

由此，我的计算结果显示行数减少了60％，而对于一个6M的行表我预计会有超过21MB的保存。它从2,762,536 KB下降到2,740,816 KB。

有人可以向我解释这种行为吗？

p.s.这不考虑任何索引。

来源

2011-04-04 Chris Kemp

也许一些删除的行？你没有尝试执行数据库清理？ – heximal 2011-04-04 09:04:21

再次尝试应对新表格。可能是因为未使用的空间还没有被分配到再次释放。只需将新缩小的表格复制到新的表格中即可看到会发生什么情况。说：减少28MB是没有意义的。如：如果这是节省，那么这些权力就会造成一个糟糕的优化举措。从某种意义上来说，它有一些缺点。 – TomTom 2011-04-04 09:06:56

请在前后给出表格定义。不知道你从哪里计算这些行大小？无论NULL_BITMAP是否为空，varchar列的最大长度都不会影响行的大小，NULL_BITMAP对每列都有一个位。内容的确如此。 – 2011-04-04 09:51:38

问题是，更改表格不会回收任何空间。删除一列只是逻辑上的，该列是隐藏，未删除。修改列类型通常会导致添加一个新列并隐藏前一个列。所有这些操作增加了表的物理大小。要回收空间“真实”，您需要重建表格。使用SQL 2008和更高版本，您可以发出ALTER TABLE ... REBUILD。在SQL 2005中，您可以发出DBCC REINDEX(table)。

来源

2011-04-04 20:56:00

我认为你需要重建表上的聚集索引。

来源

2011-04-04 20:34:26

SQL中减小的行大小并没有减小表的大小

回答

相关问题