161
6.1 Principes de l’indexation
Notons au passage ce qui s’est produit : nix$dbo indexdemo$petittexte a été recréé, puisqu’il doit contenir la clé de l’index clustered, et que celui-ci a changé.
Méfiez-vous de cet effet de bord : la modification d’un index clustered entraîne la
recréation de tous les autres index, et donc un travail important, augmenté d’un
blocage (verrouillage) de la table durant une période souvent longue (voyez plus
loin l’option ONLINE pour limiter ce temps de blocage).
L’index nix$dbo_indexdemo$petittexte, dont la clé était auparavant de 5 octets
(1 octet pour la colonne petittexte, et 4 octets pour la colonne ID), en fait maintenant (environ) 101. L’optimiseur va orienter son choix en regard de cette information. Plus la clé est longue, plus l’index sera lourd à parcourir.
La taille maximale d’une clé d’index est de 900 octets. Nous en sommes loin ici,
mais déjà, l’utilité de l’index est compromise. Un index dont la clé fait 900 octets,
est très peu utile, et même dangereux si l’index est clustered.
Couverture de requête
L’index comporte une ou plusieurs colonnes de la table dans sa clé. Cela veut donc
dire que la valeur de ces colonnes est connue de l’index, et que toutes ces valeurs
sont présentes dans son nœud feuille. Par exemple, un index sur la colonne LastName
de la table Person.Contact contient tous les LastName. Dans ce cas, nous souhaitons
dans notre requête ne récupérer que les noms, l’index tout seul suffit à y répondre :
SELECT DISTINCT LastName
FROM Person.Contact
WHERE LastName LIKE 'A%'
ORDER BY LastName;
Donnera ce plan d’exécution 1 :
|--Stream Aggregate(GROUP BY:([LastName]))
|--Index Seek(OBJECT:([nix$Person_Contact$LastName]),
SEEK:([LastName] >= N'A' AND [LastName] < N'B'),
WHERE:([LastName] like N'A%') ORDERED FORWARD)
Vous voyez que, non seulement l’index a été utilisé, mais en plus en seek (avec
une réécriture du LIKE en clause acceptable pour un seek), et non pas en scan, même
si l’estimation de la cardinalité retournée est de 911 lignes. Ceci parce qu’il n’y a pas
de bookmark lookup, donc une stratégie de seek est beaucoup plus intéressante.
Cette utilisation de l’index pour retourner les colonnes demandées, est appelée
couverture. Ici, l’index nix$Person_Contact$LastName couvre notre requête. Un
index couvrant est extrêmement intéressant pour les performances, car l’index est
une structure non seulement optimisée pour la recherche, mais plus compacte que la
table, puisqu’il contient moins de colonnes : scanner le nœud feuille d’un index non1. Sur les plans affichés en texte, nous avons simplifié le résultat pour améliorer la lisibilité. Ces
plans seront plus détaillés chez vous.
6.1 Principes de l’indexation
Notons au passage ce qui s’est produit : nix$dbo indexdemo$petittexte a été recréé, puisqu’il doit contenir la clé de l’index clustered, et que celui-ci a changé.
Méfiez-vous de cet effet de bord : la modification d’un index clustered entraîne la
recréation de tous les autres index, et donc un travail important, augmenté d’un
blocage (verrouillage) de la table durant une période souvent longue (voyez plus
loin l’option ONLINE pour limiter ce temps de blocage).
L’index nix$dbo_indexdemo$petittexte, dont la clé était auparavant de 5 octets
(1 octet pour la colonne petittexte, et 4 octets pour la colonne ID), en fait maintenant (environ) 101. L’optimiseur va orienter son choix en regard de cette information. Plus la clé est longue, plus l’index sera lourd à parcourir.
La taille maximale d’une clé d’index est de 900 octets. Nous en sommes loin ici,
mais déjà, l’utilité de l’index est compromise. Un index dont la clé fait 900 octets,
est très peu utile, et même dangereux si l’index est clustered.
Couverture de requête
L’index comporte une ou plusieurs colonnes de la table dans sa clé. Cela veut donc
dire que la valeur de ces colonnes est connue de l’index, et que toutes ces valeurs
sont présentes dans son nœud feuille. Par exemple, un index sur la colonne LastName
de la table Person.Contact contient tous les LastName. Dans ce cas, nous souhaitons
dans notre requête ne récupérer que les noms, l’index tout seul suffit à y répondre :
SELECT DISTINCT LastName
FROM Person.Contact
WHERE LastName LIKE 'A%'
ORDER BY LastName;
Donnera ce plan d’exécution 1 :
|--Stream Aggregate(GROUP BY:([LastName]))
|--Index Seek(OBJECT:([nix$Person_Contact$LastName]),
SEEK:([LastName] >= N'A' AND [LastName] < N'B'),
WHERE:([LastName] like N'A%') ORDERED FORWARD)
Vous voyez que, non seulement l’index a été utilisé, mais en plus en seek (avec
une réécriture du LIKE en clause acceptable pour un seek), et non pas en scan, même
si l’estimation de la cardinalité retournée est de 911 lignes. Ceci parce qu’il n’y a pas
de bookmark lookup, donc une stratégie de seek est beaucoup plus intéressante.
Cette utilisation de l’index pour retourner les colonnes demandées, est appelée
couverture. Ici, l’index nix$Person_Contact$LastName couvre notre requête. Un
index couvrant est extrêmement intéressant pour les performances, car l’index est
une structure non seulement optimisée pour la recherche, mais plus compacte que la
table, puisqu’il contient moins de colonnes : scanner le nœud feuille d’un index non1. Sur les plans affichés en texte, nous avons simplifié le résultat pour améliorer la lisibilité. Ces
plans seront plus détaillés chez vous.