Un indice, cluster o non cluster, può essere utilizzato da Query Optimizer se e solo se viene filtrata la chiave più a sinistra nell'indice. Quindi, se definisci un indice su colonne (A, B, C), una condizione WHERE su [email protected] , su [email protected] o su [email protected] AND [email protected] non sfrutterà completamente l'indice (vedi nota). Ciò vale anche per le condizioni di adesione. Qualsiasi filtro WHERE che includa A prenderà in considerazione l'indice:[email protected] o [email protected] AND [email protected] o [email protected] AND [email protected] o [email protected] AND [email protected] AND [email protected] .
Quindi nel tuo esempio se crei l'indice cluster su part_no come chiave più a sinistra, quindi una query che cerca un part_id specifico non utilizzare l'indice e deve esistere un indice separato non cluster su part-id .
Ora sulla domanda quale dei tanti indici dovrebbe essere il cluster uno. Se disponi di diversi modelli di query che hanno all'incirca la stessa importanza e frequenza e si contraddicono a vicenda in termini di chiavi necessarie (ad es. query frequenti da parte di uno part_no o part_id ) quindi prendi in considerazione altri fattori:
- larghezza :la chiave dell'indice cluster viene utilizzata come chiave di ricerca da all altri indici non cluster. Quindi, se scegli una chiave ampia (diciamo due colonne di univocità), stai allargando tutti gli altri indici, consumando così più spazio, generando più IO e rallentando tutto. Quindi, tra chiavi ugualmente buone dal punto di vista della lettura, scegli quella più stretta come raggruppata e rendi quelle più larghe non raggruppate.
- contesa :se disponi di schemi di inserimento ed eliminazione specifici, prova a separarli fisicamente in modo che si verifichino su porzioni diverse dell'indice cluster. Per esempio. se la tabella funge da coda con tutti gli inserimenti a un'estremità logica e tutte le eliminazioni all'altra estremità logica, provare a disporre l'indice cluster in modo che l'ordine fisico corrisponda a questo ordine logico (es. ordine di accodamento).
- partizionamento :se la tabella è molto grande e si prevede di distribuire il partizionamento, la chiave di partizionamento deve essere l'indice cluster. Un tipico esempio sono i dati storici archiviati utilizzando uno schema di partizionamento a finestra scorrevole. Anche se le entità hanno una chiave primaria logica come 'entity_id', l'indice cluster viene eseguito da una colonna datetime che viene utilizzata anche per la funzione di partizionamento.
- stabilità :una chiave che cambia spesso è un candidato scadente per una chiave in cluster poiché ogni aggiorna il valore della chiave in cluster e forza tutti indici non cluster per aggiornare la chiave di ricerca che archiviano. Poiché è probabile che l'aggiornamento di una chiave cluster trasferisca anche il record in una pagina diversa, può causare la frammentazione dell'indice cluster.
Nota:non completamente leva poiché a volte il motore sceglierà un indice non cluster da scansionare invece dell'indice cluster semplicemente perché è più stretto e quindi ha meno pagine da scansionare. Nel mio esempio se hai un indice su (A, B, C) e un filtro WHERE su [email protected] e la query proietta C , l'indice verrà probabilmente utilizzato ma non come ricerca, come scansione, perché è comunque più veloce di una scansione completa in cluster (meno pagine).
