Perché proprietà Clustered Index è abilitato su alcune colonne e non su altri?

Question

Ho sentito che non ci può essere un solo indice cluster? Posso sbagliarmi, ma sono sicuro che ho letto da qualche parte.

In uno dei miei tabella di SQL Server 2005, ho seguito colonne:

SerialNum ------- -------- BigInt chiave primaria

distretto -------- nvarchar (50)

SchemeType ------ nvarchar (50)

Quando ho aperto la tabella in modalità di progettazione utilizzando SQL Server Management Studio, noto che Indice cluster proprietà è abilitata per distretto , mentre è disattivata per SchemeType .

Se non ci può essere un solo Clustered Index, allora perché Distretto ha questa proprietà enabled quando SerialNum è già definito come chiave primaria?

Se non ci può essere di più indici cluster, quindi come attivare questa proprietà per SchemeType Colonna?

Answer 1

chiave primaria e indice cluster sono due cose diverse, anche se sono spesso usati in combinazione. Un paio di potenziali motivi vostro tavolo ha finito in questo modo:

(a) potrebbe essere stato creato con un non-cluster chiave primaria utilizzando PRIMARY KEY NONCLUSTERED, è stato aggiunto poi l'indice cluster.

(b) potrebbe sono stati aggiunti l'indice cluster, quindi la chiave primaria aggiunto (nel qual caso non possono essere raggruppati in quanto esiste già un indice cluster).

Uno di quelli avrebbe potuto essere scelte intenzionali di progettazione, incidenti, cambiamenti di ripensamento, ecc.

Ignora la struttura in vista di disegno di Management Studio. L'indice cluster è tavolo, ma è definito dalla colonna (s) specificato. Le altre colonne sono ancora tecnicamente parte della indice cluster, sono le colonne semplicemente non chiave dell'indice. Chiamata che "abilitata / disabilitata" è fuorviante.

Answer 2

Non ci può essere un solo indice cluster, in quanto l'indice cluster è i dati della tabella stessa. E 'un modo di organizzare i dati della tabella basata su una chiave di clustering. E 'simile a indice organizzato le tabelle di Oracle (IOT). Non cluster indici sono struttura di dati separati. indici cluster sono i dati si è organizzata come un b-albero.

Per impostazione predefinita SQL Server rende la chiave primaria come un indice cluster, se non c'è già uno. Sembra che nel tuo caso la chiave primaria è stato creato come un 'indice cluster non' e il Distretto colonna come 'indice cluster'.

Answer 3

Si può avere un solo indice cluster per ogni tabella. Una chiave primaria non è un indice cluster. Per rispondere alle vostre domande:

Se non ci può essere un solo Clustered Index, allora perché Distretto ha questa proprietà attivata quando SerialNum è già definito come chiave primaria? Questo perché l'indice cluster viene creato sul distretto. Solo questo mostrerà come abilitato e il resto verrà visualizzato come disabilitato.

Se non ci può essere di più indici cluster, quindi come attivare questa proprietà per la colonna SchemeType? Non si può avere più di un indice cluster su un tavolo. Si dovrà eliminare l'indice cluster in Distretto e ricreare uno per SchemeType. Se si vuole ancora mantenere l'indice cluster distretto, poi un trucco si può usare è quello di creare una vista indicizzata e quindi creare un indice cluster sulla vista per SchemeType. Potrebbe essere necessario Enterprise Edition per questo.

Answer 4

• In MySQL, che vedo da altri posti in uso, la chiave primaria e indice cluster sono sempre gli stessi.
• In SQL Server, possono essere diversi.
• In SQL Server, non ci può essere un solo indice cluster. L'indice cluster garantirà la tabella è fisicamente ordinata secondo tale indice.
• Naturalmente si può avere molti indici non cluster in aggiunta al vostro un indice cluster, e in genere si avrà un cluster e uno o pochi indici non cluster su alcune delle tabelle.
• Normalmente in SQL Server chiavi primarie hanno l'indice cluster (e penso che è il default), ma è possibile configurare un'altra colonna (o colonne) con l'indice cluster anziché.
• E 'anche possibile avere due o più colonne in che indice cluster. Non dire se la colonna SerialNum anche è in cluster, ma se si vede che entrambi sono raggruppati, allora avete un unico indice che occupa due colonne e ci sarà una proprietà intero ordine di clustering che sarà l'ordine in cui quelli colonne determinano il layout tabella fisica (ad esempio, "ordinata dal Distretto prima, e all'interno del distretto, in ordine di SerialNum"). Si noti che l'aggiunta di più colonne a questo indice cluster tenderà a ridurre le prestazioni, piuttosto che migliorarlo, a meno che l'ordine fisico corrisponde esattamente i principali casi di query contro che sufficiente tavolo per superare la pena di prestazioni INSERT ridotto che viene fornito con assicurando che l'ordinazione fisico.
• Nel vostro sistema, se il distretto è di tipo cluster (ma SerialNum non lo è), che potrebbe essere un buon progetto, se le query contro quel tavolo più spesso si uniscono contro il "distretto" o un filtro contro il "distretto" che "SerialNum". (Ho visto questo genere di cose in scenari in cui qualcosa come SerialNum è una chiave surrogata auto-increment che non viene utilizzato molto altrove nel vostro modello di dati e se gli utenti finali / applicazioni / reports hanno unisce / dove / GroupBy / clausole OrderBy con il distretto, ma raramente o mai contro SerialNum.)