Come sapere quando utilizzare gli indici e quale tipo?

Question

Ho cercato un po 'e non ho visto nessuna domanda simile, quindi ecco qui.

Come fai a sapere quando inserire un indice in una tabella? Come decidi quali colonne includere nell'indice? Quando dovrebbe essere utilizzato un indice cluster?

Un indice può mai rallentare le prestazioni delle istruzioni select? Quanti indici sono troppi e quanto è grande una tabella per trarne beneficio da un indice?

MODIFICA:

E i tipi di dati delle colonne? Va bene avere un indice su un varchar o datetime?

Answer 1

Bene, la prima domanda è facile:

Quando dovrebbe essere utilizzato un indice cluster?

Sempre. Periodo. Tranne pochissimi, rari casi limite. Un indice cluster rende una tabella più veloce, per ogni operazione. SÌ! Lo fa. Guarda l'eccellente The Clustered Index Debate continues di Kim Tripp per informazioni di base.Si cita anche i suoi criteri principali per un indice cluster:

• stretta
• statica (non cambia mai)
• unica
• se mai possibile: sempre crescente

INT IDENTITY soddisfa questo perfettamente - I GUID non lo fanno. Vedi GUID's as Primary Key per informazioni di approfondimento.

Perché stretto? Poiché la chiave di clustering viene aggiunta a ogni singola pagina di indice di ciascun indice non cluster sulla stessa tabella (per poter effettivamente cercare la riga di dati, se necessario). Non si desidera avere VARCHAR (200) nella chiave di clustering ....

Perché unico ?? Vedere sopra: la chiave di clustering è l'elemento e il meccanismo utilizzati da SQL Server per trovare in modo univoco una riga di dati. Deve essere unico. Se si seleziona una chiave di clustering non univoca, SQL Server stesso aggiungerà un unificatore di 4 byte alle chiavi. Stai attento a questo!

Avanti: indici non raggruppati. Fondamentalmente c'è una regola: qualsiasi chiave estranea in una tabella figlia che faccia riferimento a un'altra tabella deve essere indicizzata, accelererà i JOIN e altre operazioni.

Inoltre, tutte le query che hanno clausole WHERE sono un buon candidato - scegli quelle che sono state eseguite molto. Metti indici su colonne che appaiono nelle clausole WHERE, nelle istruzioni ORDER BY.

Successivo: misurare il sistema, controllare le DMV (viste di gestione dinamica) per suggerimenti sugli indici non utilizzati o mancanti e modificare il sistema più e più volte. È un processo continuo, non lo farai mai! Vedere here for info su questi due DMV (indici mancanti e non utilizzati).

Un'altra parola di avvertimento: con un carico di indici, è possibile rendere qualsiasi query SELECT molto veloce. Ma allo stesso tempo, potrebbero esserci INSERT, UPDATE e DELETE che devono aggiornare tutti gli indici coinvolti. Se solo mai SELEZIONA - impazzisci! Altrimenti, è un delicato e delicato equilibrio. Puoi sempre modificare una singola query oltre ogni aspettativa, ma il resto del tuo sistema potrebbe risentirne. Non over-index il tuo database! Metti in campo alcuni buoni indici, controlla e osserva come si comporta il sistema, quindi aggiungine un altro o due, e ancora: osserva come viene influenzata la prestazione totale del sistema.

Answer 2

Questa è davvero una domanda molto complessa, anche se un buon punto di partenza sarebbe quello di indicizzare qualsiasi colonna su cui filtrerai i risultati. vale a dire. Se si suddividono spesso prodotti in gruppi per prezzo di vendita, indicizzare la colonna sale_price della tabella prodotti per migliorare i tempi di scansione per quella query, ecc.

Answer 3

Se si esegue una query in base al valore in una colonna, è probabile che si desideri indicizzare quella colonna.

cioè

SELECT a,b,c FROM MyTable WHERE x = 1 

Si vorrebbe un indice su X.

In generale, aggiungo gli indici per le colonne che sono spesso interrogati, e aggiungo indici composti quando sto interrogando su più di un colonna.

Gli indici non danneggiano le prestazioni di un SELECT, ma possono rallentare INSERTI (o AGGIORNAMENTI) se ci sono troppe colonne di indici per tabella.

Come regola generale, iniziare aggiungendo gli indici quando ci si trova WHERE a = 123 (in questo caso, un indice per "a").

Answer 4

È necessario utilizzare un indice sulle colonne che si utilizzano per la selezione e l'ordine, ovvero le clausole WHERE e ORDER BY.

indici possono rallentare select affermazioni se ci sono molti di loro e si utilizza WHERE e ORDER BY su colonne che non sono stati indicizzati.

Come per la dimensione della tabella: diverse migliaia di righe e verso l'alto inizierebbero a mostrare vantaggi reali per l'utilizzo dell'indice.

Detto questo, ci sono strumenti automatici per fare questo, e il server SQL ha un Database Tuning Advisor che aiuterà con questo.

Answer 5

regola è chiave primaria (implicita e default cluster) e ogni colonna di chiave esterna

C'è di più, ma si potrebbe fare di peggio che usare missing index DMV di SQL Server

Un indice può rallentare un SELEZIONARE se l'ottimizzatore fa una scelta sbagliata, ed è possibile averne troppe. Troppe rallenteranno le scritture ma è anche possibile sovrapporre gli indici

Answer 6

Rispondere a quelle che posso dire che ogni tabella, non importa quanto piccola, trarrà sempre beneficio da almeno un indice in quanto deve esserci almeno un modo in cui sei interessato a cercare i dati; altrimenti perché conservarlo?

Una regola generale per l'aggiunta di indici sarebbe se fosse necessario trovare i dati nella tabella utilizzando un campo particolare o un insieme di campi.Ciò porta a quanti indici sono troppi, generalmente più indici hai gli inserimenti e gli aggiornamenti più lenti, dato che devono anche modificare gli indici ma tutto dipende da come usi i tuoi dati. Se hai bisogno di inserzioni veloci, non usarne troppe. Nella segnalazione di archivi di dati di tipo "di sola lettura" è possibile avere un numero di questi per rendere più veloci tutte le ricerche.

Sfortunatamente non esiste una regola che guidi sul numero o tipo di indici da utilizzare, sebbene l'ottimizzatore di query del DB selezionato possa fornire suggerimenti basati sulle query che si stanno eseguendo.

Per quanto riguarda gli indici cluster, è la carta Ace che è possibile utilizzare solo una volta, quindi scegliere con attenzione. Vale la pena calcolare la selettività del campo a cui si sta pensando di metterlo in quanto può essere sprecato metterlo su qualcosa come un campo booleano (esempio forzato) poiché la selettività dei dati è molto bassa.