Une table clusterisée est un B-Tree sans partie "heap" - les lignes sont stockées directement dans la structure B-Tree de l'index de clustering (clé primaire). Les nœuds du B-Tree peuvent être divisés ou fusionnés, de sorte que l'emplacement physique ou les lignes peuvent changer, nous ne pouvons donc pas avoir un simple "pointeur" d'un index secondaire vers les lignes, donc l'index secondaire doit inclure une copie complète de les champs d'index primaires pour pouvoir identifier de manière fiable les lignes.
Ceci est vrai pour Oracle, MS SQL Server et également vrai pour InnoDB .
Ce qui signifie que les index secondaires dans les tables en cluster sont "plus gros" que les index secondaires dans les tables basées sur le tas, ce qui :
- réduit le regroupement des données,
- réduit l'efficacité du cache,
- les rend plus coûteux à entretenir,
- et surtout, a des conséquences sur les performances des requêtes :
- L'interrogation via un index secondaire peut nécessiter une double recherche - une recherche via l'index secondaire pour localiser les données "clés" et une via le primaire, pour localiser la ligne elle-même (Oracle propose des optimisations intéressantes pour éviter la seconde recherche, mais InnoDB ne le fait pas, à ma connaissance).
- D'autre part, l'index secondaire couvre naturellement plus de champs, de sorte que la deuxième recherche pourrait être complètement évitée là où un index traditionnel basé sur le tas nécessiterait un accès à la table. Cependant, le même effet peut être obtenu dans l'index basé sur le tas, en y ajoutant simplement plus de champs.
Permettez-moi de citer Utilisez l'index, Luke ! :"Les avantages des tables organisées en index et des index clusterisés sont principalement limités aux tables qui n'ont pas besoin d'un second index."
Ce qui est dommage, car MySQL ne vous permet pas de choisir le clustering indépendamment du moteur de stockage.
