Colonne incluse versus index filtré

Nous travaillons actuellement avec une table nommée tb_tranfers . Ce tableau compte 40 millions de lignes et fait environ 26 Go (données de 11 Go, index de 15 Go).

10 à 15% des lignes sont des lignes supprimées en douceur ( DeletedDate n'est pas null). L'applicaiton utilise uniquement des lignes où DeletedDate est null. Toutes les requêtes adressées à ce tableau incluront une clause à cet effet.

Il y a 15 index sur cette table. L'index DMV manquant contient des suggestions pour créer des index avec DeletedDate comme colonne incluse.

Serait-il utile d'utiliser un index filtré WHERE DeleteDdate IS NULLsur les 11 index non clusterisés? Ou serait-il préférable d'avoir la colonne DeletedDate comme colonne incluse?

Oui, la modification des 11 index CN pour qu'ils soient filtrés ( CREATE INDEX ... ON ... WHERE DeletedDate IS NULL) aiderait. De cette façon, vous obtenez deux avantages:

• L'optimisateur de requêtes saura que toute ligne provenant de ces indices déjà ne satisfait vos filtres de requête sur DeletedDate, donc il n'y aura pas de rechercher l'index ordonné en clusters vérifier la DeletedDate
• Tous les index NC seront de 10 à 15% plus petits, nécessitant moins de mémoire et moins d'opérations d'E / S pour la recherche.

Le compromis est que toute requête qui s'occupe des lignes supprimées (et il doit y avoir une requête, sinon pourquoi les lignes existent-elles?) Ne pourra pas utiliser ces index NC.

Si vous utilisez TOUJOURS le DeletedDate IS NULLfiltre dans vos requêtes, alors oui, vous verrez probablement une augmentation significative des performances en ajoutant le filtre.

Il y a beaucoup moins de pages à vérifier par le moteur pour trouver les lignes pertinentes, ce qui signifie moins d'E / S (et plus de vitesse).

L'ajouter en tant que INCLUDEDchamp serait inutile . Étant donné que vous l'incluez toujours dans le filtre (mais que vous ne l'ajoutez probablement jamais à la liste SELECT), ce champ ne sera jamais référencé si vous l'ajoutez en tant que INCLUDE.

Étant donné que 85 à 90% des lignes ont DeletedDate sont NULL, il est peu probable que la sélectivité d'un index composé uniquement de DeletedDate soit suffisante pour que SQL utilise cet index. Cependant, utilisé conjointement avec d'autres colonnes plus sélectives, l'ajout de DeletedDate aux index existants devrait apporter certains avantages s'il augmente la sélectivité globale de l'index.

Comme le dit JNK, DeletedDate serait peu utile pour couvrir les index sauf si vous l'utilisez dans la clause SELECT.

Étant donné qu'il y a déjà plus de stockage pour les index que pour les données, vous voudrez peut-être également voir s'il y a une redondance dans les 15 index NC existants.