"Evitare di creare un indice cluster basato su una chiave di incremento" è un mito di SQL Server 2000 giorni?

I nostri database sono composti da molte tabelle, la maggior parte delle quali utilizza una chiave surrogata intera come chiave primaria. Circa la metà di queste chiavi primarie si trova su colonne di identità.

Lo sviluppo del database è iniziato ai tempi di SQL Server 6.0.

Una delle regole seguite dall'inizio era, Evitare di creare un indice cluster basato su una chiave di incremento , come si trova in questi Suggerimenti per l'ottimizzazione dell'indice .

Ora, usando SQL Server 2005 e SQL Server 2008, ho la forte impressione che le circostanze siano cambiate. Nel frattempo, queste colonne chiave primaria sono i primi candidati perfetti per l'indice cluster della tabella.

Il mito risale a prima di SQL Server 6.5, che ha aggiunto il blocco a livello di riga . E accennato qui da Kalen Delaney .

Aveva a che fare con i "punti critici" dell'utilizzo della pagina di dati e con il fatto che un'intera pagina 2k (SQL Server 7 e versioni successive utilizza pagine 8k) era bloccata, piuttosto che una riga inserita Modifica, febbraio 2012

Articolo autorevole trovato da Kimberly L. Tripp

"Il dibattito sull'indice cluster continua ..."

Gli hotspot erano qualcosa che abbiamo fortemente cercato di evitare PRIOR a SQL Server 7.0 a causa del blocco a livello di pagina (ed è qui che il termine hot spot è diventato un termine negativo). In realtà, non deve essere un termine negativo. Tuttavia, poiché il motore di archiviazione è stato rearchitected / riprogettato (in SQL Server 7.0) e ora include il blocco a livello di riga reale, questa motivazione (per evitare gli hotspot) non è più presente.

Modifica, maggio 2013

Il link nella risposta di lucky7_2000 sembra dire che possono esistere hotspot e che causano problemi. Tuttavia, l'articolo utilizza un indice cluster non univoco su TranTime. Ciò richiede l'aggiunta di un unificatore. Ciò significa che l'indice non è strettamente monotonicamente in aumento (e troppo ampio). Il link in quella risposta non contraddice questa risposta o i miei link

A livello personale, mi sono svegliato su database in cui ho inserito decine di migliaia di righe al secondo in una tabella che ha una colonna IDENTITY bigint come PK in cluster.

Per riassumere, nelle moderne versioni di SQL Server una chiave cluster su una colonna di identità è l'opzione preferita in questi giorni.

Kimberly Tripp ha un fantastico post sul blog proprio su questo argomento. Potrei parafrasare, ma fidati di me, non gli renderei giustizia. Buona lettura http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

Mentre sei lì, dai un'occhiata ad alcuni dei suoi altri post sull'argomento delle chiavi di clustering. C'è una buona ricchezza di conoscenze da avere dal suo sito.

controlla questo post:

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx

la creazione di un indice cluster basato su una chiave di incremento può creare punti critici per le prestazioni ...