Los niveles superiores del plan están relacionados con la eliminación de filas de la tabla base (el índice agrupado) y el mantenimiento de cuatro índices no agrupados. Dos de estos índices se mantienen fila por fila al mismo tiempo que se procesan las eliminaciones de índice agrupadas. Estos son los "+2 índices no agrupados" resaltados en verde a continuación.
Para los otros dos índices no agrupados, el optimizador ha decidido que es mejor guardar las claves de estos índices en una mesa de trabajo tempdb (el Eager Spool), luego reproducir el spool dos veces, clasificándolas por las claves del índice para promover un patrón de acceso secuencial.
La secuencia final de operaciones se refiere al mantenimiento de los xmlíndices primario y secundario , que no se incluyeron en su secuencia de comandos DDL:
No hay mucho que hacer al respecto. Los índices e xmlíndices no agrupados deben mantenerse sincronizados con los datos de la tabla base. El costo de mantener dichos índices es parte de la compensación que realiza al crear índices adicionales en una tabla.
Dicho esto, los xmlíndices son particularmente problemáticos. Es muy difícil para el optimizador evaluar con precisión cuántas filas calificarán en esta situación. De hecho, sobreestima enormemente el xmlíndice, lo que da como resultado que se otorguen casi 12 GB de memoria para esta consulta (aunque solo se usan 28 MB en tiempo de ejecución):
Podría considerar realizar la eliminación en lotes más pequeños, con la esperanza de reducir el impacto de la concesión de memoria excesiva.
También puede probar el rendimiento de un plan sin utilizar los tipos OPTION (QUERYTRACEON 8795). Este es un indicador de rastreo no documentado, por lo que solo debe probarlo en un sistema de desarrollo o prueba, nunca en producción. Si el plan resultante es mucho más rápido, puede capturar el XML del plan y usarlo para crear una Guía del plan para la consulta de producción.
