Come scegliere l'indice cluster in SQL Server?

Question

In genere, l'indice cluster viene creato in SQL Server Management Studio impostando la chiave primaria, tuttavia la mia recente domanda su PK < -> indice cluster (Meaning of Primary Key to Microsoft SQL Server 2008) ha dimostrato che non è necessario impostare PK e indice cluster in modo uguale.

Così come dovremmo scegliere indici cluster, allora? Facciamo il seguente esempio:

CREATE TABLE clienti (ID int ...) creare ordini di tabella (ID int, int) CustomerID

Vorremmo solito creare il PK/CI su entrambe le colonne ID, ma i pensato di crearlo per gli ordini in CustomerID. È la scelta migliore?

Answer 1

Secondo The Queen Of indicizzazione - Kimberly Tripp - che cosa cerca in un indice cluster è in primo luogo:

• unico
• stretta
• Statico

E se è inoltre possibile garantire:

• Modello in continuo aumento

quindi sei molto vicino ad avere la tua chiave di cluster ideale!

Controllare il suo intero blog post here e un altro molto interessante sul clustering di impatti chiave sulle operazioni di tabella qui: The Clustered Index Debate Continues.

Qualsiasi cosa come un INT (specialmente una INT IDENTITY) o possibilmente un INT e un DATETIME sono ideali come candiate. Per altri motivi, i GUID non sono affatto buoni candidati - quindi potresti avere un GUID come PK, ma non raggruppare il tuo tavolo su di esso - sarà frammentato oltre il riconoscimento e le prestazioni ne risentiranno.

Answer 2

Se siete preoccupati per il clustering di solito è per contribuire a migliorare il recupero dei dati. Nell'esempio, probabilmente vorrai tutti i record per un dato cliente contemporaneamente. Il clustering su customerID manterrà quelle righe sulla stessa pagina fisica piuttosto che sparse su più pagine nel file.

ROT: Cluster su ciò che si desidera mostrare una collezione di. Gli elementi pubblicitari in un ordine di acquisto sono l'esempio classico.

Answer 3

Un miglior candidato per un indice CLUSTERED è la chiave che si usa per riferirsi ai record più spesso.

Di solito, questo è un PRIMARY KEY, poiché è ciò che viene utilizzato nelle ricerche e/o nelle relazioni FOREIGN KEY.

Nel tuo caso, molto probabilmente il numero Orders.ID parteciperà alle ricerche e ai riferimenti, quindi è il candidato migliore per essere un'espressione di clustering.

Se si crea l'indice CLUSTERED sulle Orders.CustomerID, le seguenti cose accadono:

1. CustomerID non è unica. Per garantire univocità, una colonna speciale nascosta 32-bit nota come uniquifier verrà aggiunta a ciascun record.

2. I record nella tabella verranno memorizzati in base a questa coppia di colonne (CustomerID, uniquifier).

3. Verrà creato un indice secondario su Order.ID, con (CustomerID, uniquifier) come puntatori record.

4. Richieste simili a questo:

   SELECT * 
   FROM Orders 
   WHERE ID = 1234567 
   

   dovrà eseguire un'operazione esterna, un Clustered Seek, dal momento che non tutte le colonne sono memorizzati nell'indice sulla ID. Per recuperare tutte le colonne, il record deve essere prima collocato nella tabella raggruppata.

Questa operazione aggiuntiva richiede IndexDepth pagina come molti si legge come un semplice Clustered Seek, il IndexDepth beign O(log(n)) del numero totale dei record della tabella.