簡單的 DELETE，但複雜的執行計劃
當我執行此刪除時：
DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870…它刪除了 39,157 行。它應該很簡單，因為它是在 ETLHeaderID 上刪除，它是聚集索引和主鍵。但是（根據執行計劃）它似乎達到了 361,190 行並使用了其他索引。該表確實有一個 XML 數據類型的欄位（以防影響此 DELETE）。
有什麼想法為什麼以及如何加快此刪除速度？
此處執行計劃： http : //sharetext.org/qwDY 此處表架構：http: //sharetext.org/Vl9j
謝謝
該計劃的頂層涉及從基表（聚集索引）中刪除行，並維護四個非聚集索引。其中兩個索引在處理聚集索引刪除的同時逐行維護。這些是下面以綠色突出顯示的“+2 非聚集索引”。
對於其他兩個非聚集索引，優化器決定最好將這些索引的鍵保存到 tempdb 工作表（Eager Spool）中，然後播放 spool 兩次，按索引鍵排序以促進順序訪問模式。
最後的操作序列與維護主索引和二級
xml索引有關，這些索引未包含在您的 DDL 腳本中：
對此沒有什麼可做的。非聚集索引和
xml索引必須與基表中的數據保持同步。維護此類索引的成本是您在表上創建額外索引時做出的權衡的一部分。也就是說，這些
xml指數尤其成問題。優化器很難準確評估在這種情況下有多少行符合條件。事實上，它大大高估了xml索引，導致為該查詢授予了近 12GB 的記憶體（儘管在執行時只使用了 28MB）：
您可以考慮以較小的批量執行刪除，希望減少過多的記憶體授予的影響。
您還可以在不使用排序的情況下測試
OPTION (QUERYTRACEON 8795)計劃的性能。這是一個未記錄的跟踪標誌，因此您應該只在開發或測試系統上嘗試它，而不是在生產中。如果生成的計劃更快，您可以擷取計劃 XML 並使用它為生產查詢創建計劃指南。
