Les niveaux supérieurs du plan concernent la suppression de lignes de la table de base (l'index cluster) et la conservation de quatre index non cluster. Deux de ces index sont conservés ligne par ligne en même temps que les suppressions d'index cluster sont traitées. Ce sont les "+2 index non clusterisés" surlignés en vert ci-dessous.
Pour les deux autres index non clusterisés, l'optimiseur a décidé qu'il est préférable d'enregistrer les clés de ces index dans une table de travail tempdb (le Eager Spool), puis de lire le spool deux fois, en le triant par les clés d'index pour promouvoir un modèle d'accès séquentiel.
La séquence finale des opérations concerne la maintenance des xmlindex primaire et secondaire , qui n'étaient pas inclus dans votre script DDL:
Il n'y a pas grand-chose à faire à ce sujet. Les index non indexés et les xmlindex doivent être synchronisés avec les données de la table de base. Le coût de la maintenance de ces index fait partie du compromis que vous faites lors de la création d'index supplémentaires sur une table.
Cela dit, les xmlindices sont particulièrement problématiques. Il est très difficile pour l'optimiseur d'évaluer avec précision le nombre de lignes qui se qualifieront dans cette situation. En fait, il surestime énormément l' xmlindex, ce qui entraîne l'octroi de près de 12 Go de mémoire pour cette requête (bien que seulement 28 Mo soient utilisés au moment de l'exécution):
Vous pouvez envisager d'effectuer la suppression par lots plus petits, dans l'espoir de réduire l'impact de l'allocation de mémoire excessive.
Vous pouvez également tester les performances d'un plan sans utiliser les tris OPTION (QUERYTRACEON 8795). Il s'agit d'un indicateur de trace non documenté , vous ne devez donc l'essayer que sur un système de développement ou de test, jamais en production. Si le plan résultant est beaucoup plus rapide, vous pouvez capturer le XML du plan et l'utiliser pour créer un guide de plan pour la requête de production.