Een geclusterde tabel is een B-Tree zonder "heap"-gedeelte - rijen worden direct opgeslagen in de B-Tree-structuur van de clusteringindex (primaire sleutel). Knooppunten van de B-Tree kunnen worden gesplitst of samengevoegd, zodat de fysieke locatie of rijen kunnen veranderen, dus we kunnen geen eenvoudige "aanwijzer" hebben van een secundaire index naar de rijen, dus de secundaire index moet een volledige kopie bevatten van de primaire indexvelden om rijen betrouwbaar te kunnen identificeren.
Dit geldt voor Oracle, MS SQL Server en is ook waar voor InnoDB .
Dat betekent dat secundaire indexen in geclusterde tabellen "vetter" zijn dan secundaire indexen in op heap gebaseerde tabellen, die:
- verlaagt de gegevensclustering,
- verlaagt de effectiviteit van de cache,
- maakt ze duurder in onderhoud,
- en vooral, heeft gevolgen voor de prestaties van zoekopdrachten:
- Voor het doorzoeken van een secundaire index is mogelijk dubbele opzoeking vereist - een opzoeking via de secundaire index om de "sleutel" -gegevens te vinden en een via de primaire om de rij zelf te lokaliseren (Oracle heeft enkele interessante optimalisaties om de tweede opzoeking te vermijden, maar InnoDB niet, voor zover ik weet).
- Aan de andere kant, de secundaire index dekt meer velden, zodat de tweede zoekopdracht helemaal kan worden vermeden waar een traditionele op heap gebaseerde index een tabeltoegang vereist. Hetzelfde effect kan echter worden bereikt in de op heap gebaseerde index, door er simpelweg meer velden aan toe te voegen.
Dat is jammer, aangezien MySQL je de clustering niet onafhankelijk van de storage-engine laat kiezen.