Sql-Server
為什麼要創建和刪除隨機索引來解決此性能問題？
我有一個有 17,093,139 行的大堆表。該表是數據庫中使用最頻繁的表。由於這是一個堆表，因此該表中只有非聚集索引。我定期重建/重組該表上的碎片索引。
現在我們經常面臨這個問題：訪問該表的大量查詢會突然開始比平時花費更長的時間。當我檢查時，我觀察到查詢的執行計劃已經改變。
我創建並刪除了一個隨機的非聚集索引，這解決了這個問題。
我沒有得到的是，是什麼導致這些突然的緩慢隨機出現，以及在後台創建和刪除索引對錶的作用是什麼，以修復索引重建工作沒有做的事情？
我需要找出究竟是什麼觸發了這些減速，以便找到一個永久的解決方案，因為我不能只是保持創建和刪除索引來每次都解決這個問題。
在這裡的任何幫助將不勝感激。
刪除表上的索引將刷新從記憶體中引用此表的執行計劃。（我認為索引需要包含一個在查詢中引用但不能 100% 確定的列）。
然後 SQL 建構一個新的執行計劃來“修復”您的問題。
您可以嘗試重建統計資訊（而不是刪除索引），或手動刪除執行計劃（請參閱 Sp_blitz 儲存過程以輕鬆獲取命令）。您可能會有相同的行為（查詢修復）。如果是這樣，那麼您可能需要閱讀參數嗅探問題。
Ps 很少有一個沒有聚群索引的表。通常，我見過的唯一好的情況是日誌表，您希望在其中快速完成插入……但在您的情況下，如果您有非聚集索引，那麼無論如何您都會有插入的成本。
您可能正在目睹的可能與參數嗅探有關-
1- 可能您應該擷取緩慢的計劃並將其保存以供以後的新計劃進行比較
- 嘗試從記憶體中刷新該特定計劃，以防您知道您保存的計劃很慢的特定程序。
- 如果速度更快，請保存新計劃。
- 比較兩個計劃，如果看到不同的結果，看看參數值是多少。
基於此，您可以採取進一步措施。但在此之前，最好知道這是否真的如此。