Nous utilisons tous les jours de nombreux indexes : heure, calendrier, annuaire, sommaire et index d’un livre, …
Passons aux bases de données : quelle est la différence entre un index cluster et un index non-cluster ?
Si la différence peut sembler obscure de prime abord, le choix des index est crucial pour la performance globale de la base de données, et de coût quasiment nul en terme de modifications à apporter au schéma de celle-ci.
Les deux types d’index sont-ils complémentaires ? Quelles sont les conséquences du choix de la clé de ceux-ci ?
Rappelons d’abord la différence entre les deux types d’indexes :
=> Dans un index cluster, les niveaux intermédiaires de l’arbre de tri contiennent les valeurs de la clé (et un RowID), selon l’ordre physique de celle-ci, et seul le niveau feuille de l’index contient les pages de données de la table.
En ce sens :
– il ne peut y avoir qu’un seul index cluster par table,
Рun index cluster est plus sujet aux splits de page (mais on peut les ̩viter en sp̩cifiant la colonne comme auto-incr̩ment̩e),
– un index cluster est un doublon de la table,
– une analogie en est l’index que vous trouvez au début d’un livre : il montre de quelle façon est organisé le livre dans l’ordre physique des pages de celui-ci.
Sous SQL Server, les indexes cluster sont créés :
Рimplicitement lors de la sp̩cification de la cl̩ primaire de la table,
– lors de l’ajout d’une contrainte d’unicité spécifiant CLUSTERED (si la table ne comporte pas déjà de clé primaire).
=> Un index non-cluster est ordonné suivant l’ordre logique des valeurs de sa clé (et un keyID), et son niveau feuille ne contient pas les pages de données, mais les lignes de l’index cluster.
En ce sens :
– il peut y avoir plusieurs indexes non-cluster sur une table,
– un index non-cluster est moins sujet aux splits de page,
– une analogie en est l’index que vous trouvez à a fin d’un livre : il est ordonné suivant les titres des sujets qui sont traités, mais il référence la clé physique du livre : les numéros de page.
Sous SQL Server, tous les indexes sont implicitement créés non-cluster, à l’exception des indexes de clé primaire.
Dès lors, on comprend que le choix de la clé de l’index cluster d’une table est très important, puisqu’il influe sur la qualité des indexes non-cluster qui seront posés sur la même table.
Le choix des indexes reste complexe et à réaliser avec parcimonie, parce qu’il est difficile de trouver le parfait arbitrage entre les performances des requêtes et le coût de mise à jour de ceux-ci.
Pour la préservation des performances générales d’une base de données, leur maintenance et un audit sur leur qualité et leur absence doit être régulièrement effectué.
ElSuket