SQL Server: quando utilizzare l'indice cluster e non cluster?

99

Conosco le differenze principali tra gli indici cluster e non cluster e ho una comprensione di come funzionano effettivamente. Comprendo come gli indici cluster e non cluster migliorano le prestazioni di lettura. Ma una cosa di cui non sono sicuro è che quali sarebbero i motivi per cui avrei scelto uno piuttosto che l'altro.

Ad esempio: se una tabella non ha un indice cluster, si dovrebbe creare un indice non cluster e qual è il vantaggio di fare

sql-server  indexing  clustered-index  non-clustered-index  query-tuning 
— armulator
fonte
3
Grazie per aver risposto. Ne sono già consapevole. La mia domanda è se ci sarebbe una situazione in cui la creazione di un indice non cluster sarebbe più vantaggiosa della creazione di un indice cluster
— armulator
2
Sì, dovresti evitare un indice cluster quando; la colonna ha una cardinalità bassa, nessun ordine particolare, aggiornata frequentemente, non sequenziale, è un composto di molte colonne ...
— TI
Grazie per la tua risposta. È utile
— armulator
1
Forse questa domanda potrebbe aiutarti: stackoverflow.com/questions/5070529/…
— David García González
— Michael Freidgeim

Risposte:

117

Voglio solo mettere una parola di avvertimento: scegli con molta attenzione il tuo indice cluster! Ogni tabella di dati "normale" dovrebbe avere un indice cluster, poiché avere un indice cluster velocizza davvero molte operazioni - sì, accelera , persino inserisce ed elimina! Ma solo se scegli un buon indice cluster.

È la struttura di dati più replicata nel database di SQL Server. Anche la chiave di clustering farà parte di ogni indice non cluster della tabella.

È necessario prestare la massima attenzione quando si sceglie una chiave di clustering: dovrebbe essere:

  • stretto (4 byte ideale)

  • unico (dopotutto è il "puntatore di riga". Se non lo rendi unico, SQL Server lo farà per te in background, costandoti un paio di byte per ogni voce moltiplicato per il numero di righe e il numero di indici non cluster hai - questo può essere molto costoso!)

  • statico (non cambiare mai, se possibile)

  • idealmente in continuo aumento in modo da non finire con un'orribile frammentazione dell'indice (un GUID è l'esatto opposto di una buona chiave di clustering, per quel motivo particolare)

  • dovrebbe essere non annullabile e idealmente anche a larghezza fissa: a è varchar(250)una chiave di clustering molto scarsa

Qualsiasi altra cosa dovrebbe davvero essere il secondo e il terzo livello di importanza dietro questi punti ...

Guarda alcuni dei post del blog di Kimberly Tripp ( The Queen of Indexing ) sull'argomento: tutto ciò che ha scritto nel suo blog è assolutamente inestimabile - leggilo, digeriscilo - vivilo!

— marc_s
fonte
1
Grazie Marc_s per la chiara spiegazione. Ma tecnicamente parlando, cosa fa non clusteredindex per noi. che importanza ha ..?
— hud
@nad: un indice non cluster ben scelto può velocizzare le tue ricerche: invece di dover confrontare potenzialmente milioni di righe di dati con i tuoi criteri di ricerca, puoi trovare una determinata riga con solo 4, 5 confronti. Questo fa una differenza enorme !
— marc_s
1
@MuriloKunze: leggi il post sul blog di Kim Tripp sull'argomento - spiega in dettaglio perché è così
— marc_s
5
Mi dispiace, ma dov'è la risposta alla domanda "SQL Server: quando utilizzare l'indice cluster e non cluster?" ?
— Eduard
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.