En klustrad tabell är ett B-träd utan "heap"-del - rader lagras direkt i B-Tree-strukturen för klustringsindexet (primärnyckel). Noder i B-trädet kan delas eller sammanfogas, så den fysiska platsen eller raderna kan ändras, så vi kan inte ha en enkel "pekare" från ett sekundärt index till raderna, så det sekundära indexet måste innehålla en fullständig kopia av de primära indexfälten för att på ett tillförlitligt sätt kunna identifiera rader.
Detta gäller för Oracle, MS SQL Server och är även sant för InnoDB .
Vilket innebär att sekundära index i klustrade tabeller är "fetare" än sekundära index i heapbaserade tabeller, vilket:
- sänker dataklustringen,
- sänker cachens effektivitet,
- gör dem dyrare att underhålla,
- och viktigast av allt, har konsekvenser för frågeprestanda:
- Att söka genom ett sekundärt index kan kräva dubbel uppslag - en uppslagning genom det sekundära indexet för att hitta "nyckel"-data och en genom den primära, för att lokalisera själva raden (Oracle har några intressanta optimeringar för att undvika den andra uppslagningen, men Det gör inte InnoDB, såvitt jag vet).
- Å andra sidan täcker det sekundära indexet naturligtvis a> fler fält, så den andra uppslagningen kunde undvikas helt där ett traditionellt heapbaserat index skulle kräva en tabellåtkomst. Samma effekt kan dock uppnås i det heapbaserade indexet genom att helt enkelt lägga till fler fält till det.
Låt mig citera Använd indexet, Luke! :"Fördelarna med indexorganiserade tabeller och klustrade index är oftast begränsade till tabeller som inte behöver ett andra index."
Vilket är synd, eftersom MySQL inte låter dig välja klustringen oberoende av lagringsmotorn.