Una tabella cluster è un B-Tree senza porzione "heap":le righe vengono archiviate direttamente nella struttura B-Tree dell'indice di clustering (chiave primaria). I nodi del B-Tree possono essere divisi o uniti, quindi la posizione fisica o le righe possono cambiare, quindi non possiamo avere un semplice "puntatore" da un indice secondario alle righe, quindi l'indice secondario deve includere una copia completa di i campi dell'indice primario per poter identificare le righe in modo affidabile.
Questo è vero per Oracle, MS SQL Server ed è vero anche per InnoDB .
Ciò significa che gli indici secondari nelle tabelle raggruppate sono "più grassi" degli indici secondari nelle tabelle basate su heap, che:
- riduce il clustering dei dati,
- riduce l'efficacia della cache,
- le rende più costose da mantenere
- e, soprattutto, ha conseguenze sulle prestazioni della query:
- L'esecuzione di query tramite un indice secondario può richiedere una doppia ricerca:una ricerca tramite l'indice secondario per individuare i dati "chiave" e una tramite il primario, per individuare la riga stessa (Oracle ha alcune ottimizzazioni interessanti per evitare la seconda ricerca, ma InnoDB no, per quanto ne so).
- D'altra parte, l'indice secondario naturalmente copre più campi, quindi la seconda ricerca potrebbe essere evitata del tutto laddove un tradizionale indice basato su heap richiederebbe un accesso alla tabella. Tuttavia, lo stesso effetto può essere ottenuto nell'indice basato su heap, semplicemente aggiungendo più campi ad esso.
Lasciami citare Usa l'indice, Luke! :"I vantaggi delle tabelle organizzate per indici e degli indici cluster sono per lo più limitati alle tabelle che non necessitano di un secondo indice."
Il che è un peccato, dal momento che MySQL non ti consente di scegliere il clustering indipendentemente dal motore di archiviazione.
