192
Chapitre 6. Utilisation des index
Scan count 1, logical reads 792, physical reads 0, read-ahead reads 44,
lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server essaie autant que possible d’éviter le bookmark lookup. Le plan
généré utilise donc une jointure entre les deux index : l’index nonclustered
IX_TransactionHistory_ProductID est utilisé pour chercher les lignes correspondant
au critère, et une jointure de type nested loop est utilisée pour parcourir l’index clustered à chaque occurrence trouvée, pour extraire toutes les données de la ligne
(SELECT *).
Cette jointure doit donc lire bien plus de pages que celles de l’index, puisqu’il
faut aller chercher toutes les colonnes de la ligne. À chaque ligne trouvée, il faut
parcourir l’index clustered pour retrouver la page de données et en extraire la ligne.
En l’occurrence cela entraîne la lecture de 1 979 pages.
Nous avons vu que l’index clustered utilise 788 pages. Le scan de cet index, selon
les informations d’entrées/sorties, a coûté 792 lectures de page. D’où sortent les quatre pages supplémentaires ?
Selon la documentation de la vue sys.allocation_units dont la valeur 788 est
tirée, la colonne data_pages exclut les pages internes de l’index et les pages de gestion d’allocation (IAM). Les quatre pages supplémentaires sont donc probablement
ces pages internes. Nous pouvons le vérifier rapidement grâce à DBCC IND :
DBCC IND (AdventureWorks, 'Production.TransactionHistory', 1)
où le troisième paramètre est l’ID de l’index. L’index clustered prend toujours
l’ID 1.
Le résultat de cette commande nous donne 792 pages, donc 788 sont des pages de
données, plus une page d’IAM (PageType = 10) et trois pages internes (PageType =
2). Voilà pour le mystère.
Résumés de chaîne
Les résumés de chaîne (string summary) sont une addition aux statistiques dans SQL
Server 2005. Comme vous l’avez vu dans le header retourné par DBCC
SHOW_STATISTICS, la valeur de String Index indique si les statistiques pour cette clé
de l’index contiennent des résumés de chaîne. Il s’agit d’un échantillonnage à l’intérieur d’une colonne de type chaîne de caractères (un VARCHAR par exemple), qui
permet à l’optimiseur d’avoir une meilleure estimation du nombre de lignes que la
requête va retourner. Ces statistiques ne sont pas utiles pour un seek d’index, bien
sûr, puisque la recherche ne pourra se faire sur une clé d’index, mais elles permettent
simplement d’améliorer l’estimation de cardinalité. Les résumés de chaîne ne
couvrent que 80 caractères de la donnée (les 40 premiers et 40 derniers si la chaîne
est plus longue).
Chapitre 6. Utilisation des index
Scan count 1, logical reads 792, physical reads 0, read-ahead reads 44,
lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server essaie autant que possible d’éviter le bookmark lookup. Le plan
généré utilise donc une jointure entre les deux index : l’index nonclustered
IX_TransactionHistory_ProductID est utilisé pour chercher les lignes correspondant
au critère, et une jointure de type nested loop est utilisée pour parcourir l’index clustered à chaque occurrence trouvée, pour extraire toutes les données de la ligne
(SELECT *).
Cette jointure doit donc lire bien plus de pages que celles de l’index, puisqu’il
faut aller chercher toutes les colonnes de la ligne. À chaque ligne trouvée, il faut
parcourir l’index clustered pour retrouver la page de données et en extraire la ligne.
En l’occurrence cela entraîne la lecture de 1 979 pages.
Nous avons vu que l’index clustered utilise 788 pages. Le scan de cet index, selon
les informations d’entrées/sorties, a coûté 792 lectures de page. D’où sortent les quatre pages supplémentaires ?
Selon la documentation de la vue sys.allocation_units dont la valeur 788 est
tirée, la colonne data_pages exclut les pages internes de l’index et les pages de gestion d’allocation (IAM). Les quatre pages supplémentaires sont donc probablement
ces pages internes. Nous pouvons le vérifier rapidement grâce à DBCC IND :
DBCC IND (AdventureWorks, 'Production.TransactionHistory', 1)
où le troisième paramètre est l’ID de l’index. L’index clustered prend toujours
l’ID 1.
Le résultat de cette commande nous donne 792 pages, donc 788 sont des pages de
données, plus une page d’IAM (PageType = 10) et trois pages internes (PageType =
2). Voilà pour le mystère.
Résumés de chaîne
Les résumés de chaîne (string summary) sont une addition aux statistiques dans SQL
Server 2005. Comme vous l’avez vu dans le header retourné par DBCC
SHOW_STATISTICS, la valeur de String Index indique si les statistiques pour cette clé
de l’index contiennent des résumés de chaîne. Il s’agit d’un échantillonnage à l’intérieur d’une colonne de type chaîne de caractères (un VARCHAR par exemple), qui
permet à l’optimiseur d’avoir une meilleure estimation du nombre de lignes que la
requête va retourner. Ces statistiques ne sont pas utiles pour un seek d’index, bien
sûr, puisque la recherche ne pourra se faire sur une clé d’index, mais elles permettent
simplement d’améliorer l’estimation de cardinalité. Les résumés de chaîne ne
couvrent que 80 caractères de la donnée (les 40 premiers et 40 derniers si la chaîne
est plus longue).