Os níveis mais altos do plano estão relacionados à remoção de linhas da tabela base (o índice clusterizado) e à manutenção de quatro índices não clusterizados. Dois desses índices são mantidos linha por linha ao mesmo tempo em que as exclusões de índice em cluster são processadas. Estes são os "+2 índices não agrupados" destacados em verde abaixo.
Para os outros dois índices não clusterizados, o otimizador decidiu que é melhor salvar as chaves desses índices em uma mesa de trabalho tempdb (o Eager Spool) e depois executar o spool duas vezes, classificando pelas chaves de índice para promover um padrão de acesso seqüencial.
A sequência final de operações está relacionada à manutenção dos xmlíndices primário e secundário , que não foram incluídos no seu script DDL:
Não há muito a ser feito sobre isso. Índices e xmlíndices não clusterizados devem ser mantidos sincronizados com os dados na tabela base. O custo de manutenção desses índices faz parte do compromisso que você faz ao criar índices extras em uma tabela.
Dito isto, os xmlíndices são particularmente problemáticos. É muito difícil para o otimizador avaliar com precisão quantas linhas se qualificarão nessa situação. De fato, ela superestima demais o xmlíndice, resultando em quase 12 GB de memória sendo concedidos para essa consulta (embora apenas 28 MB sejam usados em tempo de execução):
Você pode considerar a exclusão em lotes menores, na esperança de reduzir o impacto da concessão excessiva de memória.
Você também pode testar o desempenho de um plano sem as classificações OPTION (QUERYTRACEON 8795). Este é um sinalizador de rastreamento não documentado, portanto, você deve experimentá-lo apenas em um sistema de desenvolvimento ou teste, nunca em produção. Se o plano resultante for muito mais rápido, você poderá capturar o XML do plano e usá-lo para criar um Guia de Plano para a consulta de produção.
