Простий ВИДАЛЕНО, але складний план виконання

Коли я запускаю це видалення:

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

... він видаляє 39157 рядків. Це повинно бути простим, оскільки він видаляє на ETLHeaderID, який є кластерним індексом та первинним ключем. Але (згідно плану виконання), здається, він набирає 361 190 рядків і використовує інші індекси. У таблиці є поле з типом даних XML (на випадок, коли це впливає на DELETE).

Будь-які ідеї, чому і як я можу пришвидшити цю УДАЛИТИ?

План виконання тут: http://sharetext.org/qwDY Схема таблиці тут: http://sharetext.org/Vl9j

Дякую

Найвищі рівні плану стосуються видалення рядків із базової таблиці (кластерного індексу) та підтримання чотирьох некластеризованих індексів. Два з цих індексів підтримуються строково за рядком, при цьому обробляються кластерні видалення індексу. Це "+2 некластеризовані індекси", виділені зеленим кольором внизу.

Для інших двох некластеризованих індексів оптимізатор вирішив, що найкраще зберегти ключі цих індексів до робочого столу tempdb (Eager Spool), а потім відтворити котушку двічі, сортуючи за індексними клавішами для просування послідовного шаблону доступу.

Заключна послідовність операцій стосується збереження первинних та вторинних xmlіндексів, які не були включені у ваш сценарій DDL:

З цим робити не багато. Некластеризовані індекси та xmlіндекси повинні зберігатися синхронізованими з даними в базовій таблиці. Витрати на підтримку таких індексів є частиною компромісу, який ви здійснюєте, створюючи додаткові індекси на таблиці.

Однак, xmlіндекси особливо проблемні. Оптимізатору дуже важко точно оцінити, скільки рядків буде кваліфіковано в цій ситуації. Насправді це дико завищує xmlпоказник, в результаті чого для цього запиту надається майже 12 ГБ пам'яті (хоча під час виконання використовується лише 28 МБ):

Ви можете розглянути можливість видалення в менших партіях, сподіваючись зменшити вплив надмірного надання пам'яті.

Ви також можете перевірити виконання плану без використання сортування OPTION (QUERYTRACEON 8795). Це прапор без документації, тому слід спробувати його лише на розробці або тест-системі, ніколи у виробництві. Якщо отриманий план набагато швидше, ви можете захопити XML плану та використовувати його для створення посібника по плану для виробничого запиту.

Ви на правильному шляху - проблема в індексі XML. Очевидно, є первинний, а також вторинний індекс XML.

При виконанні DELETE проти базової таблиці (ETLHeaders) дані також потрібно видалити з кожного індексу цієї таблиці. Цей наклад може бути значним, особливо для індексів XML.

Індекс, що викликає велику тривалість, є вторинним індексом XML [XML_IX_ETLHeaders_Property]. 39,157 рядків у вашій "реляційній таблиці" відносяться до 361,190 рядків у первинному індексі XML [XML_IX_ETLHeaders]. І ці рядки 361k потрібно сортувати, щоб можна було використовувати для видалення вторинного індексу. І така операція сортування викликає тривалість запиту. (Як бічне зауваження, статистика індексу обох індексів xml здається далекою: фактичний розмір даних 361k рядків основного індексу xml становить 160MB, тоді як орієнтовний розмір даних майже 4TB (так, 4 TerraByte !!)) .

Єдиний варіант, який я бачу, щоб прискорити цей запит, - це усунути вторинний індекс XML. Залежно від даних може бути кращим варіантом подрібнення XML-даних у реляційній таблиці.