この削除を実行すると：
DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870... 39,157行を削除します。これは、クラスター化インデックスと主キーであるETLHeaderIDを削除しているため、単純なはずです。しかし、（実行計画によると）361,190行に達し、他のインデックスを使用しているようです。テーブルには、XMLデータ型のフィールドがあります（このDELETEに影響する場合）。
なぜ、どのように私はこのDELETEを高速化できるのでしょうか？
実行計画はこちら：http : //sharetext.org/qwDY テーブルスキーマはこちら：http : //sharetext.org/Vl9j
ありがとう
回答:
計画の最上位レベルは、ベーステーブル（クラスター化インデックス）から行を削除し、4つの非クラスター化インデックスを維持することに関係しています。これらのインデックスのうち2つは、クラスター化インデックスの削除が処理されるときに、行ごとに維持されます。これらは、以下の緑色で強調表示されている「+2非クラスター化インデックス」です。
他の2つの非クラスター化インデックスについては、オプティマイザーはこれらのインデックスのキーをtempdb作業テーブル（Eagerスプール）に保存してから、スプールを2回再生し、インデックスキーでソートして、シーケンシャルアクセスパターンを促進するのが最善であると判断しました。
操作の最後のシーケンスはxml、DDLスクリプトに含まれていないプライマリインデックスとセカンダリインデックスの維持に関係しています。
これについて行うことはあまりありません。非クラスター化インデックスとxmlインデックスは、ベーステーブルのデータと常に同期している必要があります。そのようなインデックスを維持するコストは、テーブルに追加のインデックスを作成するときに行うトレードオフの一部です。
とはxmlいえ、インデックスは特に問題があります。この状況でオプティマイザが適格な行数を正確に評価することは非常に困難です。実際、これはxmlインデックスを大幅に過大評価しているため、このクエリには約12 GBのメモリが割り当てられています（実行時に使用されるのは28 MBのみです）。
過度のメモリ許可の影響を減らすことを期待して、小さなバッチで削除を実行することを検討できます。
を使用して、並べ替えなしで計画のパフォーマンスをテストすることもできOPTION (QUERYTRACEON 8795)ます。これは文書化されていないトレースフラグなので、本番環境では決して開発またはテストシステムでのみ試行してください。結果のプランがはるかに高速である場合、プランXMLをキャプチャし、それを使用して本番クエリのプランガイドを作成できます。
あなたは正しい軌道に乗っています-XMLインデックスが問題です。明らかに、プライマリXMLインデックスとセカンダリXMLインデックスがあります。
ベーステーブル（ETLHeaders）に対してDELETEを実行する場合、このテーブルのすべてのインデックスからもデータを削除する必要があります。このオーバーヘッドは、特にXMLインデックスの場合に重要になる可能性があります。
長い期間を引き起こしているインデックスは、セカンダリXMLインデックス[XML_IX_ETLHeaders_Property]です。「リレーショナルテーブル」の39,157行は、プライマリXMLインデックス[XML_IX_ETLHeaders]の361,190行を参照します。また、セカンダリインデックスの削除に使用できるように、これらの361k行をソートする必要があります。そして、この並べ替え操作はクエリの長い期間を引き起こしています。（補足として、両方のxmlインデックスのインデックス統計はかなりずれているようです：プライマリxmlインデックスの361k行の実際のデータサイズは160MBですが、推定データサイズはほぼ4TBです（そう、4テラバイト!!）） 。
このクエリを高速化する唯一の選択肢は、セカンダリXMLインデックスを削除することです。データによっては、XMLデータをリレーショナルテーブルに細断する方が適切な場合があります。