159
6.1 Principes de l’indexation
Le lookup (bookmark lookup), ou « recherche de clés » dans la traduction française, correspond à la nécessité, lorsqu’une recherche sur l’index nonclustered a
atteint le nœud feuille, de retrouver les lignes correspondantes dans la table. Les
colonnes lookup de la vue sys.dm_db_index_usage_stats indiquent que l’index a
participé à une opération de recherche de clés. Elle n’a de sens que sur un index clustered. En effet, la recherche de clé ne se produit qu’à partir d’un index nonclustered.
Cette recherche peut se faire soit sur un RID (Row ID, ou identifiant de ligne) dans
le cas d’une table « heap » (sans index clustered), soir sur la clé de l’index clustered si
la table en comporte un. Dans ce dernier cas, la recherche de clé se fait donc par un
parcours de l’index clustered. C’est ce parcours qui est indiqué dans les colonnes lookup de la vue dynamique.
Le bookmark lookup est une opération lourde, parce qu’elle provoque des lectures
aléatoires (random IO), c’est-à-dire des lectures non pas en séquence de lignes dans
les pages, mais de lignes qui peuvent se situer n’importe où. Comme lorsque vous
cherchez dans un dictionnaire : il est beaucoup plus coûteux de prendre chaque nom
dans l’index de fin d’ouvrage, et de vous rendre à la bonne page, que d’avoir un dictionnaire dont les entrées sont déjà triées, et de feuilleter les pages sur la lettre qui
vous intéresse. L’optimiseur essaie donc d’éviter autant que possible le bookmark lookup, en choisissant un scan dès que le nombre de lignes à retourner atteint un certain
seuil.
Un index a une profondeur (le nombre de niveaux de l’arbre) et une étendue (le
nombre de clés, et physiquement de pages à chaque niveau). Bien entendu, l’étendue augmente au fur et à mesure que l’on descend dans les niveaux.
6.1.2 Choix de l’index
Dans quel cas choisir un index clustered, et dans quel cas choisir un index
nonclustered ?
Comme le dernier niveau de l’index est la ligne elle-même, toute recherche à travers l’index clustered sera très rapide, puisque l’étape de lookup sera inutile. L’index
clustered est à choisir soigneusement, car, bien entendu, on ne peut créer qu’un seul
index clustered par table (comme il n’existe qu’un seul ordre alphabétique dans un
dictionnaire… ce n’est que dans le monde de la physique quantique qu’un objet peut
se dupliquer et prendre deux natures différentes. Une table ne peut, elle, être physiquement triée par deux clés différentes à la fois).
Comme l’index clustered ordonne physiquement les lignes, il est aussi idéal sur
des recherches de plages de valeurs. Les clauses de recherche utilisant un BETWEEN, ou
une syntaxe comme :
SELECT *
FROM dbo.indexdemo
WHERE id > 10 AND id < 50;
profitera aussi grandement d’un index clustered.
6.1 Principes de l’indexation
Le lookup (bookmark lookup), ou « recherche de clés » dans la traduction française, correspond à la nécessité, lorsqu’une recherche sur l’index nonclustered a
atteint le nœud feuille, de retrouver les lignes correspondantes dans la table. Les
colonnes lookup de la vue sys.dm_db_index_usage_stats indiquent que l’index a
participé à une opération de recherche de clés. Elle n’a de sens que sur un index clustered. En effet, la recherche de clé ne se produit qu’à partir d’un index nonclustered.
Cette recherche peut se faire soit sur un RID (Row ID, ou identifiant de ligne) dans
le cas d’une table « heap » (sans index clustered), soir sur la clé de l’index clustered si
la table en comporte un. Dans ce dernier cas, la recherche de clé se fait donc par un
parcours de l’index clustered. C’est ce parcours qui est indiqué dans les colonnes lookup de la vue dynamique.
Le bookmark lookup est une opération lourde, parce qu’elle provoque des lectures
aléatoires (random IO), c’est-à-dire des lectures non pas en séquence de lignes dans
les pages, mais de lignes qui peuvent se situer n’importe où. Comme lorsque vous
cherchez dans un dictionnaire : il est beaucoup plus coûteux de prendre chaque nom
dans l’index de fin d’ouvrage, et de vous rendre à la bonne page, que d’avoir un dictionnaire dont les entrées sont déjà triées, et de feuilleter les pages sur la lettre qui
vous intéresse. L’optimiseur essaie donc d’éviter autant que possible le bookmark lookup, en choisissant un scan dès que le nombre de lignes à retourner atteint un certain
seuil.
Un index a une profondeur (le nombre de niveaux de l’arbre) et une étendue (le
nombre de clés, et physiquement de pages à chaque niveau). Bien entendu, l’étendue augmente au fur et à mesure que l’on descend dans les niveaux.
6.1.2 Choix de l’index
Dans quel cas choisir un index clustered, et dans quel cas choisir un index
nonclustered ?
Comme le dernier niveau de l’index est la ligne elle-même, toute recherche à travers l’index clustered sera très rapide, puisque l’étape de lookup sera inutile. L’index
clustered est à choisir soigneusement, car, bien entendu, on ne peut créer qu’un seul
index clustered par table (comme il n’existe qu’un seul ordre alphabétique dans un
dictionnaire… ce n’est que dans le monde de la physique quantique qu’un objet peut
se dupliquer et prendre deux natures différentes. Une table ne peut, elle, être physiquement triée par deux clés différentes à la fois).
Comme l’index clustered ordonne physiquement les lignes, il est aussi idéal sur
des recherches de plages de valeurs. Les clauses de recherche utilisant un BETWEEN, ou
une syntaxe comme :
SELECT *
FROM dbo.indexdemo
WHERE id > 10 AND id < 50;
profitera aussi grandement d’un index clustered.