我有一個SQL 2005數據庫中的表是全新的。作爲我們應用程序部署的一部分，我們使用大約2.6M行加載表。一旦完成，表格上的索引全部重新生成。然後讓用戶進入系統並對該表進行查詢超時。然後，我可以重建索引（使用與導入後使用的完全相同的腳本），並且查詢速度很快。必須在表上重建索引兩次
我已檢查索引重建後沒有其他主要數據更改。關於還有什麼可能導致這種行爲的任何想法？
這裏是什麼樣的索引重建腳本看起來像一個示例：
DROP INDEX dbo.My_Table.Index1
DROP INDEX dbo.My_Table.Index2
ALTER INDEX PK_My_Table ON dbo.My_Table REBUILD
CREATE NONCLUSTERED INDEX Index1 ON dbo.My_Table (column_1 ASC)
CREATE NONCLUSTERED INDEX Index2 ON dbo.My_Table (column_2 ASC)
統計，大概，但不是在指標
優化器將拿起變化的行數/第一個查詢中沒有統計。它決定重建/創建統計信息。
但是：可能存在與索引無關的列級別統計信息。
第二屆重建無關的統計目的，因爲列統計已經存在，但它強制執行計劃將被丟棄，並重新評估
編輯：
。 ..列表統計不被 索引重建過程所觸及...
我會假設你的導入過程的東西導致索引數據翻過許多數據頁進行分配。重建它們可以解決這個問題。
我懷疑第一次簡單地添加索引並不是重建統計數據。嘗試在加載後在表上執行DBCC DBREINDEX。你也可能想要確保你有一個聚集索引。
PK上有一個聚集索引。謝謝你的想法。 – 2009-08-11 20:40:35
也許只需要很長時間才能完成索引。在第一次索引重建後，您等了多久？
更新：我發現它確實是一個週末的事情，這意味着索引不會在第一次正確工作。在這種情況下，除目前爲止所說的話外，我沒有任何建議。
我們通常會在週末測試導入情況，在週日和週一晚上完成後仍然是問題。當我運行腳本時，只需要2到5分鐘即可完成。 （還是）感謝你的建議。 – 2009-08-11 20:37:55
刪除索引之前你做了你的批量插入的數據。這將允許數據更快插入。加載數據之前，還應禁用相關表格上的任何觸發器。
然後，添加您的索引。這可以避免您目前正在執行的不必要的冗餘索引重建。
另外，正如一位用戶已經指出的那樣，使用DBCC DBREINDEX比刪除&重新添加索引更有意義。當然，你也可以update statistics。
更新：由於DBCC DBREINDEX已被棄用（命令，而不是概念），因此使用ALTER INDEX和REBUILD選項。
感謝您的建議。雖然進口不是一個直接的批量插入。 更新統計數據不會解決大數據更改（如碎片等）導致的問題。 DBCC DBREINDEX在SQL Server的斬波塊上，我相信。 – 2009-08-11 20:36:45
我記得在創建索引時SQL Server使用當前統計信息的地方。如果統計數據過期，正在創建的索引可針對錯誤的情況進行優化，並給出效果不佳的結果。
嘗試在創建索引之前更新表格上的統計信息。
在BOL的UPDATE STATISTICS條目表明會發生這種情況：
數據庫引擎保留有關在每個索引中的鍵值分佈的統計信息，並使用這些統計信息來確定在查詢中使用該索引或索引處理。用戶可以使用CREATE STATISTICS語句在非索引列上創建統計信息。查詢優化取決於分發步驟的準確性：
- 如果索引中的鍵值存在重大更改，請在該索引上重新運行UPDATE STATISTICS。
- 如果索引列中的大量數據已被添加，更改或刪除（即，如果鍵值分佈已更改），或者該表已使用TRUNCATE TABLE語句截斷並重新填充，請使用更新統計。
既然您已經導入數百萬行到一個空表，我會說，你已經打了上面的案例之一。
感謝您的帖子。我會嘗試更新統計數據，但我認爲你對這個過程的理解有點偏離。統計信息不用於創建索引 - 它們用於確定查詢計劃以及應使用哪些索引。索引創建僅依賴於索引的數據。 – 2009-08-12 18:37:58
是的你是對的。我正在將創作與重新索引混合在一起。我認爲我最初閱讀的內容涉及到某些重新索引命令（不更新統計信息），實際上在重新索引時使用當前統計信息。現在我找不到這個參考，所以它也可能是錯誤的。 – adrianbanks 2009-08-13 08:51:07
感謝您的建議。問題的癥結在於，它沒有通過第一次重建來解決。在用戶報告問題後，我總是必須再次進行此操作。 – 2009-08-11 20:39:55