Database SQL Server con PID GUID con cluster: cambiare indice cluster o passare a GUID sequenziali (comb)?

Question

Abbiamo un database in cui tutti i PK sono GUID e la maggior parte dei PK è anche l'indice cluster per la tabella. Sappiamo che questo è sbagliato (a causa della natura casuale dei GUID). Quindi, sembra che ci siano fondamentalmente due opzioni qui (a meno di buttare fuori GUID come PK del tutto, cosa che non possiamo fare (almeno non in questo momento)).

• È possibile modificare l'algoritmo di generazione GUID ad es. quello che usa NHibernate, come descritto in this post, o
• , potremmo, per le tabelle che sono sotto l'uso più pesante, passare a un altro indice cluster, ad es. una colonna IDENTITY e mantenere i GUID "casuali" come PK.

È possibile fornire raccomandazioni generali in tale scenario?

L'applicazione in questione ha più di 500 tabelle, la più grande attualmente a circa 1,5 milioni di righe, alcuni tavoli intorno a 500 000 righe e il resto significativamente più basso (la maggior parte di essi ben al di sotto di 10 K).

Inoltre, l'applicazione è già installata in diversi siti di clienti, pertanto è necessario prendere in considerazione eventuali effetti negativi per i clienti esistenti.

Grazie!

Answer 1

Se sei in grado di cambiare la tua guidare generazione a una generazione di guide sequenziale facilmente quindi è probabilmente la tua opzione di vittoria rapida. Il comando sequenziale interromperà la frammentazione sul tavolo rimanendo come indice cluster. Lo svantaggio principale con una guida sequenziale è che poi diventano supponibili, cosa che spesso non è desiderata e il motivo per cui i guids sono usati in primo luogo.

Se si scende lungo la rotta Identity per la chiave primaria in cluster e quindi solo un indice sulla colonna guid, si otterrà comunque molta frammentazione nel proprio indice di guida. Tuttavia il fatto che il tavolo non sarà più frammentato sarà un enorme guadagno.

Infine, so che hai detto che non puoi farlo per ora, ma, se non hai BISOGNO di usare i guids come indice, allora rimuovi tutti questi problemi.

Answer 2

La mia opinione è chiara: utilizzare INT IDENTITY per la chiave di clustering. Questo è di gran lunga la migliore chiave di clustering più ottimale, perché la sua:

• piccola
• stabile (non dovrebbe mai cambiare)
• unici
• sempre crescenti GUID

sequenziali di sono sicuramente un molto meglio dei normali GUID casuali, ma c'è ancora quattro volte più grande di un INT (16 contro 4 byte) e questo sarà un fattore se hai molte righe nella tua tabella, e anche molti indici non in cluster su quella tabella . La chiave di clustering viene aggiunta a ogni singolo indice non cluster, in modo tale da aumentare significativamente l'effetto negativo di avere 16 vs 4 byte di dimensione. Più byte significa più pagine su disco e in SQL Server RAM e quindi più I/O su disco e più lavoro per SQL Server.

È possibile mantenere il GUID come chiave primaria, laddove appropriato, ma in tal caso, consigliamo vivamente di aggiungere un IDENTITÀ INT separata a quella tabella e rendere INT quella chiave di clustering. L'ho fatto io stesso con un certo numero di tabelle di grandi dimensioni, ei risultati sono sorprendenti: la frammentazione della tabella è scesa da 99 e più percento a pochi percento, e le prestazioni sono decisamente migliori.

Partenza serie eccellente di Kimberly Tripp sul perché GUID sono male come chiavi di clustering in SQL Server qui:

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc