Верхние уровни плана связаны с удалением строк из базовой таблицы (кластеризованный индекс) и поддержкой четырех некластеризованных индексов. Два из этих индексов поддерживаются построчно, в то же время обрабатываются удаления кластеризованных индексов. Это «+2 некластеризованных индекса», выделенных зеленым цветом ниже.
Для двух других некластеризованных индексов оптимизатор решил, что лучше всего сохранить ключи этих индексов на рабочем столе tempdb (Eager Spool), а затем дважды воспроизвести спул, отсортировав его по ключам индекса, чтобы обеспечить последовательный шаблон доступа.
Последняя последовательность операций связана с поддержанием первичных и вторичных xmlиндексов, которые не были включены в ваш сценарий DDL:
С этим ничего не поделаешь. Некластеризованные индексы и xmlиндексы должны синхронизироваться с данными в базовой таблице. Стоимость обслуживания таких индексов является частью компромисса, который вы делаете при создании дополнительных индексов для таблицы.
Тем не менее, xmlиндексы являются особенно проблематичными. Оптимизатору очень сложно точно оценить, сколько строк будет соответствовать этой ситуации. Фактически, он xmlсильно переоценивает индекс, в результате чего для этого запроса выделяется почти 12 ГБ памяти (хотя во время выполнения используется только 28 МБ):
Вы могли бы рассмотреть возможность удаления в меньших пакетах, надеясь уменьшить влияние чрезмерного предоставления памяти.
Вы также можете проверить производительность плана без использования сортировок OPTION (QUERYTRACEON 8795). Это недокументированный флаг трассировки, поэтому его следует использовать только в системе разработки или тестирования, а не в производстве. Если результирующий план намного быстрее, вы можете захватить XML плана и использовать его для создания руководства по плану для производственного запроса.
