Sono d'accordo con Cade Roux.
Questo articolo dovrebbe portarti sulla strada giusta:
- Indici in SQL Server 2005/2008 – Procedure consigliate, parte 1
- Indici in SQL Server 2005/2008 – Parte 2 – Elementi interni
Una cosa da notare, gli indici cluster dovrebbero avere una chiave univoca (una colonna di identità che consiglierei) come prima colonna. Fondamentalmente aiuta i tuoi dati a inserirsi alla fine dell'indice e non causa molti IO del disco e divisioni di pagina.
In secondo luogo, se stai creando altri indici sui tuoi dati e sono costruiti in modo intelligente, verranno riutilizzati.
per esempio. immagina di cercare una tabella su tre colonne
stato, provincia, cap.
- a volte cerchi solo per stato.
- A volte cerchi per stato e provincia.
- cerchi frequentemente per stato, contea, codice postale.
Quindi un indice con stato, contea, zip. verrà utilizzato in tutte e tre queste ricerche.
Se si esegue una ricerca abbastanza frequente solo tramite zip, l'indice sopra non verrà utilizzato (comunque da SQL Server) poiché zip è la terza parte di tale indice e l'ottimizzatore di query non vedrà quell'indice come utile.
È quindi possibile creare un indice solo su Zip che verrebbe utilizzato in questa istanza.
A proposito, possiamo trarre vantaggio dal fatto che con l'indicizzazione multicolonna la prima colonna dell'indice è sempre utilizzabile per la ricerca e quando si cerca solo per "stato" è efficiente ma non efficiente come l'indice a colonna singola su "stato" '
Immagino che la risposta che stai cercando sia che dipende dalle tue clausole where delle tue query utilizzate di frequente e anche dal tuo gruppo di by.
L'articolo aiuterà molto. :-)
