In una tabella senza un indice cluster (una tabella heap), le pagine di dati non sono collegate tra loro, quindi l'attraversamento delle pagine richiede un cerca nella mappa di allocazione dell'indice .
Una tabella in cluster, tuttavia, ha le sue pagine di dati collegate in un elenco doppiamente collegato - rendere un po' più veloci le scansioni sequenziali. Ovviamente, in cambio, hai il sovraccarico di occuparti di mantenere in ordine le pagine di dati su INSERT , UPDATE e DELETE . Una tabella heap, tuttavia, richiede una seconda scrittura nell'IAM.
Se la tua richiesta ha un RANGE operatore (es.:SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), una tabella raggruppata (in un ordine garantito) sarebbe più efficiente, poiché potrebbe utilizzare le pagine di indice per trovare le pagine di dati pertinenti. Un heap dovrebbe scansionare tutte le righe, poiché non può fare affidamento sull'ordine.
E, naturalmente, un indice cluster ti consente di eseguire una RICERCA DI INDICI CLUSTERED, che è praticamente ottimale per le prestazioni... un heap senza indici comporterebbe sempre una scansione della tabella.
Quindi:
-
Per la tua query di esempio in cui selezioni tutte le righe, l'unica differenza è l'elenco doppiamente collegato mantenuto da un indice cluster. Questo dovrebbe rendere la tua tabella cluster appena un po' più veloce di un heap con un numero elevato di righe.
-
Per una query con un
WHEREclausola che può essere (almeno parzialmente) soddisfatta dall'indice cluster, uscirai in vantaggio a causa dell'ordinamento, quindi non dovrai scansionare l'intera tabella. -
Per una query che non è soddisfatta dall'indice cluster, sei praticamente pari... di nuovo, l'unica differenza è quella lista doppiamente collegata per la scansione sequenziale. In entrambi i casi, non sei ottimale.
-
Per
INSERT,UPDATEeDELETEun mucchio può o non può vincere. L'heap non deve mantenere l'ordine, ma richiede una seconda scrittura nell'IAM. Penso che la differenza di prestazioni relative sarebbe trascurabile, ma anche piuttosto dipendente dai dati.
Microsoft ha un whitepaper che confronta un indice cluster con un indice non cluster equivalente su un heap (non esattamente lo stesso di cui ho discusso sopra, ma vicino). La loro conclusione è fondamentalmente quella di inserire un indice cluster su tutte le tabelle. Farò del mio meglio per riassumere i loro risultati (di nuovo, nota che stanno davvero confrontando un indice non cluster con un indice cluster qui, ma penso che sia relativamente comparabile):
INSERTperformance:l'indice cluster vince di circa il 3% a causa della seconda scrittura necessaria per un heap.UPDATEperformance:l'indice cluster vince di circa l'8% grazie alla seconda ricerca necessaria per un heap.DELETEprestazioni:l'indice cluster vince di circa il 18% a causa della seconda ricerca necessaria e della seconda eliminazione necessaria dall'IAM per un heap.- singolo
SELECTperformance:l'indice cluster vince di circa il 16% grazie alla seconda ricerca necessaria per un heap. - intervallo
SELECTperformance:l'indice cluster vince di circa il 29% grazie all'ordinamento casuale di un heap. INSERTsimultaneo :la tabella heap vince del 30% sotto carico a causa delle divisioni di pagina per l'indice cluster.
