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中減小的行大小並沒有減小表的大小

回答

相關問題