SQL索引空間不會降低刪除數據從表

後，我最近嘗試清潔桌子。該表是40GB大，索引空間是400MB。從表中刪除了很多記錄後，它減少到4GB，但索引空間仍然是大約400MB。我認爲這可能是因爲索引碎片時，我刪除記錄，然後我重建索引，但索引空間仍然是398MB。我不明白，如果表格大小減少了10倍，爲什麼索引空間不會按比例減少？SQL索引空間不會降低刪除數據從表

指數的構建

ALTER TABLE [CADIS_PROC].[DC_UPPREBBO_INFO_VALUE] 
ADD PRIMARY KEY CLUSTERED ( 
[CADIS_ID] ASC, 
[SOURCE] ASC, 
[SOURCE_KEY] ASC, 
[FILE_DATE] ASC)WITH 
(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO

腳本重建索引

ALTER INDEX IndexName ON Schema.Table 
REBUILD; 
GO

我如何檢查索引碎片，我也對對點擊桌子上看到它的財產，它顯示的大小表和索引空間。

SELECT index_id, name, avg_fragmentation_in_percent 
FROM sys.dm_db_index_physical_stats (DB_ID(), OBJECT_ID(), NULL, NULL, NULL)

該索引是表中唯一的索引，它是碎片的0.8％。

來源

2015-12-20 JOHN

當你說你重建索引時，你究竟做了什麼？你也可以提供有關索引的任何細節，因爲這也有幫助。 –

索引創建如下 ALTER TABLE [CADIS_PROC]。[DC_UPPREBBO_INFO_VALUE] WITH（PAD_INDEX ADD聚集主鍵（ [CADIS_ID] ASC， [SOURCE] ASC， [SOURCE_KEY] ASC， [FILE_DATE] ASC ）= OFF，STATISTICS_NORECOMPUTE = OFF，SORT_IN_TEMPDB = OFF，IGNORE_DUP_KEY = OFF，ONLINE = OFF，ALLOW_ROW_LOCKS = ON，ALLOW_PAGE_LOCKS = ON）ON [PRIMARY] GO' 我使用SQL Management Studio中的選項來重建索引[鏈接]（https://msdn.microsoft.com/en-us /library/ms189858.aspx） – JOHN

您是否還可以包含用於報告空間使用情況的命令。順便說一句，你可能想編輯你的原始問題以提供這些信息。 –

聚簇索引是該表。表中的數據按聚簇索引定義的順序物理存儲。

如果該表只有聚簇索引並且沒有非聚簇索引，我認爲索引空間幾乎爲零。

我有一個只有聚集索引的表。 SSMS顯示：

Data space = 3,215.539 MB 
Index space = 5.211 MB  (not zero, but pretty close)

每個夜晚系統重建使用此命令索引：

ALTER INDEX ALL ON <table name> REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, ONLINE = OFF, SORT_IN_TEMPDB = ON)

嘗試它，而不是指定索引的名字。

要測量表使用的磁盤空間，請嘗試使用sp_spaceused。它有一個參數@updateusage，這可能很有用。

嘗試運行這樣的過程：

EXEC sp_spaceused @objname = N'[dbo].[TableName]', @updateusage = N'TRUE'

這個存儲過程MSDN文章有這樣一個字條：

當刪除或重建大型索引，或者刪除或截斷大表，數據庫引擎將推遲實際的頁面釋放，並將其相關的鎖定，直到事務提交後。推遲的刪除操作不會立即釋放分配的空間。因此， sp_spaceused在丟棄後立即返回的值或截斷大對象的可能不會反映可用的實際磁盤空間。有關延期分配的更多信息，請參閱刪除和重建大型對象。

看看相關文章Dropping and Rebuilding Large Objects以及。

來源

2015-12-20 02:32:00

意識到，一個聚集索引是建立與不同於非聚集索引實際的數據頁。這可能是值得嘗試刪除，然後重新創建索引，而不是使用REBUILD看看有什麼影響。

從MSDN here

在指數

減少不成引用當一個索引的方式，碎片被影響查詢性能支離破碎，有三種選擇減少碎片：

刪除並重新創建聚簇索引。

重新創建聚集索引重新分配數據和結果在完整的數據頁面。可以使用CREATE INDEX中的 FILLFACTOR選項來配置充滿程度。此方法的缺點是索引在丟棄和重新創建週期期間處於脫機狀態，並且操作是原子性的。如果索引創建中斷，則索引不會重新創建。有關更多信息，請參閱CREATE INDEX （Transact-SQL）。

使用ALTER INDEX REORGANIZE，更換爲DBCC INDEXDEFRAG，到重新排序索引的葉級頁按邏輯順序。因爲這是一個在線操作，所以在語句正在運行時索引可用。如果沒有已經完成失敗的工作，操作也可能中斷。在這種方法的缺點是，它不會做重組數據作爲索引重建操作的好工作，而且不更新邏輯順序的指數statistics.reorder葉級頁。

使用ALTER INDEX REBUILD替換DBCC DBREINDEX，以聯機或脫機重建索引。有關更多信息，請參閱ALTER INDEX（Transact-SQL）。

您已經嘗試＃3，如果你的實際可能要考慮1或2有瓜葛的效果。如果您只是試圖瞭解觀察到的行爲，請在可以重建其數據庫的開發/測試服務器上使用數據庫副本（或至少相關的表）。您也可以嘗試僅使用非聚集索引進行比較。

就我個人而言，我一直懷疑任何報表工具對聚集索引的索引性能和空間利用率都有所懷疑，因爲它們必須區分索引和共享相同分配空間的數據。

來源

2015-12-20 01:36:57

我也試過重組，我讀了一些[測試]（http://sqlstudies.com/2014/12/11/drop-index-and-create-index-vs-alter-index-rebuild/）說有聚集索引上的drop和recreate與重建沒有區別。我不明白的是，爲什麼當我刪除行時，索引空間與實際表大小的減少成比例地減少，而索引沒有分片。 – JOHN

SQL索引空間不會降低刪除數據從表

回答

相關問題