重建后索引碎片顯著增加

我用Google搜尋了這個，我知道有些人說索引碎片並不重要，但他們繼續描述可能重要的場景。我的可能就是這樣的場景。

我在一個巨大的表（8600 萬行）上有一個索引，其中大約 33% 是碎片化的。

幾天前，我開始注意到某些查詢花費的時間太長。似乎他們沒有使用其中一個索引，即使查詢是以它們應該使用索引的方式編寫的（我可能錯了沒有使用索引）

所以我做的一件事就是查看索引碎片。有 33% 是我在沒有任何東西使用表的時候進行了重建（除了作為測試，我在重建索引的同時對錶執行了查詢——也許是愚蠢的）。

重建大約需要 10 到 20 分鐘。出於某種原因，我沒有立即檢查碎片。第二天我檢查了它（查詢仍然很慢），發現它已經增加到 56.06%！

如果我嘗試再次重建，我會變得更糟嗎？我應該嘗試重組嗎？（我讀到微軟建議如果碎片小於 30% 則進行重組，如果碎片超過 30% 則建議重建）

**免責聲明：**我知道這裡可能存在一些不好的做法（表格大小、設計或任何東西）我沒有創建這個，我只是繼承了它的責任。

**編輯：**我冒著再次重建的風險。這一次立即檢查。它是 0.01 碎片化的。大約十分鐘後我再次檢查，大約有 1% 的碎片。我再次檢查了大約一分鐘的間隔，它逐漸變得更加碎片化。幾個小時後，它現在有 53.55% 是碎片化的。

輸出@@version：

Microsoft SQL Server 2005 - 9.00.3042.00 (X64)

2007 年 2 月 10 日 00:59:02

版權所有 (c) 1988-2005

Windows NT 6.0 上的 Microsoft Corporation 標準版（64 位）（Build 6001：Service Pack 1）

自動收縮已打開（在數據庫屬性對話框中顯示“真”）

---

編輯：一些進一步的資訊，為問題提供更多細節……

在每天的固定時間，該表會批量更新大約 50,000 到 100,000 行新數據。在一天的剩餘時間裡，沒有更新或新記錄，它純粹是查詢數據。

主鍵在“recordid”上，它是一個自動增量欄位。新插入的價值高於表中的任何其他內容，因此不必將數據夾在索引中的現有數據之間。

這是相關索引的創建索引程式碼…

USE [EWS]
GO

/****** Object:  Index [IX_AmtoteAccountActivity]    Script Date: 03/03/2016 21:07:14 ******/
CREATE CLUSTERED INDEX [IX_AmtoteAccountActivity] ON [dbo].[AmtoteAccountActivity] 
(
   [AccountNumber] ASC,
   [_Date] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, 
IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, 
ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

如果它很重要/相關（我不確定是否相關），這裡是主鍵的創建索引程式碼……

USE [EWS]
GO

/****** Object:  Index [PK_AmtoteAccountActivity]  Script Date: 03/03/2016 21:10:11 ******/
ALTER TABLE [dbo].[AmtoteAccountActivity] ADD  CONSTRAINT [PK_AmtoteAccountActivity] 
PRIMARY KEY NONCLUSTERED 
(
   [RecordID] 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

最後，正如@Shanky 和@KookieMonster 所建議的那樣，我相信碎片（在重建後穩步增長）是由該數據庫的 auto_shrink 引起的。

就像@KookieMonster 注意到的那樣，您打開了自動收縮功能。收縮命令的缺點之一是再次將您的索引碎片化：

http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

頁面完整度為 98.23%。這意味著每頁只有 140 字節的空閒空間。這大於最小行大小。因此，在鍵範圍中間的任何插入，以及可能的任何更新，都會導致頁面拆分和碎片。

由於索引中有大約 300 萬頁，您需要影響大約 100 萬行以獲得 30% 的碎片。您是否有以這種量級寫入的程序？

引用自：https://dba.stackexchange.com/questions/131132