En klynget tabel er et B-træ uden "heap"-del - rækker gemmes direkte i B-Tree-strukturen af klyngeindekset (primær nøgle). Noder i B-træet kan opdeles eller samles, så den fysiske placering eller rækker kan ændre sig, så vi kan ikke have en simpel "peger" fra et sekundært indeks til rækkerne, så det sekundære indeks skal indeholde en komplet kopi af de primære indeksfelter for at kunne identificere rækker pålideligt.
Dette gælder for Oracle, MS SQL Server og er også sandt for InnoDB .
Hvilket betyder, at sekundære indekser i klyngede tabeller er "federe" end sekundære indekser i heap-baserede tabeller, hvilket:
- sænker dataklyngningen,
- sænker effektiviteten af cachen,
- gør dem dyrere at vedligeholde,
- og vigtigst af alt, har konsekvenser for forespørgselsydeevne:
- Forespørgsel gennem et sekundært indeks kan kræve dobbelt opslag - et opslag gennem det sekundære indeks for at finde "nøgle"-dataene og et gennem det primære, for at finde selve rækken (Oracle har nogle interessante optimeringer for at undgå det andet opslag, men Det gør InnoDB mig bekendt ikke).
- På den anden side dækker det sekundære indeks naturligvis a> flere felter, så det andet opslag helt kunne undgås, hvor et traditionelt heap-baseret indeks ville kræve en tabeladgang. Den samme effekt kan dog opnås i det heap-baserede indeks ved blot at tilføje flere felter til det.
Lad mig citere Brug indekset, Luke! :"Fordelene ved indeksorganiserede tabeller og klyngede indekser er for det meste begrænset til tabeller, der ikke har brug for et andet indeks."
Hvilket er en skam, da MySQL ikke lader dig vælge klynge uafhængigt af lagermotoren.