Sql-Server
查詢優化器會忽略碎片索引嗎？
場景：我有一個帶有索引的重型 OLTP 表。我在一天或更短的時間內看到許多插入、更新和刪除以及索引碎片。在索引建構的第一天，優化器使用索引，第二天或第三天，優化器完全跳過它。這是針對完全相同的查詢。
我腦海中的問題：為什麼有些查詢計劃會跳過索引，因為創建索引是為了幫助優化這些計劃？
這篇文章的問題：優化器是否可以跳過嚴重碎片化的索引，例如我們有 10 億條記錄並建立索引的場景，然後兩個小時後，所有十億條記錄都被刪除，我們有 5 億條新記錄？
我開始認為向該表添加索引根本沒有幫助，因為表的性質（數據快速輸入，數據快速輸出），但只是想了解為什麼有一天優化器會在其計劃中使用索引，但第二天，它不會。
AFAIK 優化器不知道索引碎片。如果它選擇掃描碎片索引的計劃，這可能是一個問題。
不過，優化器知道分配的數據大小。如果索引頁有很多可用空間（可能是由於內部碎片），這會使索引不太可能被使用。50% 的空白空間意味著要掃描的 IO 量的兩倍。不過，對於隨機訪問來說，這在很大程度上並不重要。
不過，這並不是一個巨大的影響。它可以解釋你所看到的。
如果這個小影響將查詢計劃翻轉為不使用索引，那麼在查詢優化器看來，索引從一開始就不是超級好。這可能暗示您可以改進它。
此外，優化器似乎猜測有多少索引記憶體在緩衝池中。XML 執行計劃中有一些對此的引用。我對此沒有詳細的了解。
我開始認為向該表添加索引根本無濟於事
我不會走那麼遠。也許您只需要在正確的位置進行重建或 drop-DML-create 序列？或者，這可能只是一個查詢調整問題（提出一個包含實際執行計劃的新問題）。