Quali sono le differenze tra un indice cluster e un indice non cluster?

Quali sono le differenze tra a clusterede a non-clustered index?

Indice cluster

• Solo uno per tabella
• Più veloce da leggere rispetto a non cluster poiché i dati vengono archiviati fisicamente in ordine di indice

Indice non cluster

• Può essere usato più volte per tabella
• Più veloce per le operazioni di inserimento e aggiornamento rispetto a un indice cluster

Entrambi i tipi di indice miglioreranno le prestazioni quando si selezionano i dati con campi che utilizzano l'indice ma rallentano le operazioni di aggiornamento e inserimento.

A causa dell'inserimento e dell'aggiornamento più lenti, gli indici cluster devono essere impostati su un campo che è normalmente incrementale, ad esempio ID o Timestamp.

SQL Server utilizzerà normalmente un indice solo se la sua selettività è superiore al 95%.

Gli indici cluster ordinano fisicamente i dati sul disco. Ciò significa che non sono necessari dati aggiuntivi per l'indice, ma può esserci un solo indice cluster (ovviamente). L'accesso ai dati mediante un indice cluster è più rapido.

Tutti gli altri indici devono essere non cluster. Un indice non cluster ha un duplicato dei dati dalle colonne indicizzate mantenute ordinate insieme ai puntatori alle righe dei dati effettivi (puntatori all'indice cluster se ce n'è uno). Ciò significa che l'accesso ai dati tramite un indice non cluster deve passare attraverso un ulteriore livello di indiretta. Tuttavia, se selezioni solo i dati disponibili nelle colonne indicizzate, puoi recuperare i dati direttamente dai dati dell'indice duplicati (ecco perché è una buona idea SELEZIONARE solo le colonne che ti servono e non usare *)

Gli indici cluster vengono archiviati fisicamente nella tabella. Ciò significa che sono i più veloci e puoi avere un solo indice cluster per tabella.

Gli indici non cluster vengono archiviati separatamente e puoi averne quanti ne desideri.

L'opzione migliore è impostare l'indice cluster sulla colonna univoca più utilizzata, in genere PK. Dovresti sempre avere un indice cluster ben selezionato nelle tue tabelle, a meno che un motivo molto convincente - non riesca a pensarne uno solo, ma ehi, potrebbe essere là fuori - per non farlo si presenta.

Indice cluster

1. Può esserci un solo indice cluster per una tabella.
2. Di solito realizzato sulla chiave primaria.
3. I nodi foglia di un indice cluster contengono le pagine di dati.

Indice non cluster

1. Per una tabella possono esistere solo 249 indici non cluster (fino alla versione sql 2005 le versioni successive supportano fino a 999 indici non cluster).
2. Di solito fatto su qualsiasi tasto.
3. Il nodo foglia di un indice non cluster non è costituito dalle pagine di dati. Invece, i nodi foglia contengono righe di indice.

Indice cluster

• In una tabella può essere presente un solo indice cluster
• Ordinare i record e archiviarli fisicamente in base all'ordine
• Il recupero dei dati è più veloce degli indici non cluster
• Non è necessario spazio aggiuntivo per memorizzare la struttura logica

Indice non cluster

• Può esserci un numero qualsiasi di indici non cluster in una tabella
• Non influisce sull'ordine fisico. Creare un ordine logico per le righe di dati e utilizzare i puntatori ai file di dati fisici
• L'inserimento / aggiornamento dei dati è più veloce dell'indice cluster
• Utilizzare spazio aggiuntivo per memorizzare la struttura logica

A parte queste differenze, devi sapere che quando la tabella è non cluster (quando la tabella non ha un indice cluster) i file di dati non sono ordinati e utilizza la struttura di dati Heap come struttura di dati.

Cluster in sostanza significa che i dati sono in quell'ordine fisico nella tabella. Questo è il motivo per cui puoi averne solo uno per tabella.

Unclustered significa che è "solo" un ordine logico.

Professionisti:

Gli indici cluster funzionano perfettamente per gli intervalli (ad es. Selezionare * da my_table dove my_key tra @min e @max)

In alcune condizioni, il DBMS non dovrà svolgere attività di ordinamento se si utilizza un'istruzione orderby.

Contro:

Gli indici cluster possono rallentare gli inserimenti perché i layout fisici dei record devono essere modificati man mano che i record vengono inseriti se le nuove chiavi non sono in ordine sequenziale.

Un indice cluster è essenzialmente una copia ordinata dei dati nelle colonne indicizzate.

Il vantaggio principale di un indice cluster è che quando la query (ricerca) individua i dati nell'indice, non è necessario alcun IO aggiuntivo per recuperare tali dati.

Il sovraccarico di mantenere un indice cluster, specialmente in una tabella frequentemente aggiornata, può portare a scarse prestazioni e per questo motivo potrebbe essere preferibile creare un indice non cluster.

Un database indicizzato ha due parti: un set di record fisici, che sono disposti in un ordine arbitrario, e un set di indici che identificano la sequenza in cui i record devono essere letti per produrre un risultato ordinato secondo un criterio. Se non esiste alcuna correlazione tra la disposizione fisica e l'indice, la lettura di tutti i record in ordine potrebbe richiedere l'esecuzione di molte operazioni di lettura indipendenti a singolo record. Poiché un database potrebbe essere in grado di leggere dozzine di record consecutivi in ​​meno tempo di quanto richiederebbe la lettura di due record non consecutivi, le prestazioni potrebbero essere migliorate se anche i record consecutivi nell'indice vengono archiviati consecutivamente su disco.

Ad esempio, se si dovesse iniziare con un database vuoto non cluster e aggiungere 10.000 record in sequenza casuale, i record verrebbero probabilmente aggiunti alla fine nell'ordine in cui sono stati aggiunti. La lettura del database in ordine di indice richiederebbe 10.000 letture a un record. Se si dovesse usare un database cluster, tuttavia, il sistema potrebbe verificare quando si aggiunge ogni record se il record precedente era archiviato da solo; se lo scoprisse, potrebbe scrivere quel record con quello nuovo alla fine del database. Potrebbe quindi esaminare il record fisico prima degli slot in cui risiedevano i record spostati e vedere se il record che seguiva era memorizzato da solo. Se lo scoprisse, potrebbe spostare quel record in quel punto. L'uso di questo tipo di approccio comporterebbe il raggruppamento di più record in coppie,

In realtà, i database in cluster utilizzano algoritmi più sofisticati di così. Una cosa fondamentale da notare, tuttavia, è che c'è un compromesso tra il tempo necessario per aggiornare il database e il tempo necessario per leggerlo in sequenza. Il mantenimento di un database cluster aumenterà in modo significativo la quantità di lavoro richiesta per aggiungere, rimuovere o aggiornare i record in qualsiasi modo che influisca sulla sequenza di ordinamento. Se il database verrà letto in sequenza molto più spesso di quanto verrà aggiornato, il clustering può essere una grande vittoria. Se verrà aggiornato spesso ma raramente letto in sequenza, il clustering può essere un grande svantaggio delle prestazioni, soprattutto se la sequenza in cui gli elementi vengono aggiunti al database è indipendente dal loro ordinamento per quanto riguarda l'indice cluster.

Un indice cluster in realtà descrive l'ordine in cui i record sono fisicamente memorizzati sul disco, quindi il motivo per cui puoi averne solo uno.

Un indice non cluster definisce un ordine logico che non corrisponde all'ordine fisico sul disco.

Potresti aver passato la parte teorica dai post sopra:

-L'indice cluster come possiamo vedere i punti direttamente per registrare cioè il suo diretto quindi ci vuole meno tempo per una ricerca. Inoltre non ci vorrà memoria / spazio extra per memorizzare l'indice

-Mentre, nell'Indice non cluster, indirettamente indirizza all'Indice cluster, quindi accederà al record effettivo, a causa della sua natura indiretta ci vorrà un po 'più di tempo per accedere. Inoltre ha bisogno della propria memoria / spazio per memorizzare il indice

// Copiato da MSDN, il secondo punto dell'indice non cluster non è chiaramente menzionato nelle altre risposte.

clustered

• Gli indici cluster ordinano e memorizzano le righe di dati nella tabella o nella vista in base ai loro valori chiave. Queste sono le colonne incluse nella definizione dell'indice. Può esserci un solo indice cluster per tabella, poiché le righe di dati stesse possono essere archiviate in un solo ordine.
• L'unica volta in cui le righe di dati in una tabella vengono archiviate in ordine ordinato è quando la tabella contiene un indice cluster. Quando una tabella ha un indice cluster, la tabella viene chiamata tabella cluster. Se una tabella non ha un indice cluster, le sue righe di dati vengono archiviate in una struttura non ordinata chiamata heap.

non cluster

• Gli indici non cluster hanno una struttura separata dalle righe di dati. Un indice non cluster contiene i valori chiave dell'indice non cluster e
  ogni voce del valore chiave ha un puntatore alla riga di dati che contiene il valore chiave.
• Il puntatore da una riga di indice in un indice non cluster a una riga di dati è chiamato localizzatore di righe. La struttura del localizzatore di righe dipende dal fatto che le pagine di dati siano memorizzate in un heap o in una tabella di cluster. Per un heap, un localizzatore di riga è un puntatore alla riga. Per una tabella cluster, il localizzatore di righe è la chiave di indice cluster.