Le cinque principali considerazioni per la progettazione di indici di database in SQL Server

Gli indici del database vengono utilizzati per velocizzare diverse operazioni sulle tabelle. Tuttavia, prima di creare un indice, è importante sapere se hai davvero bisogno di un indice? E se devi creare un indice quali sono i punti importanti da tenere a mente? È qui che entra in gioco la progettazione dell'indice del database.

Questo articolo mira a rispondere a queste domande sulla progettazione dell'indice di database e gettare luce su alcune delle principali considerazioni che uno sviluppatore di database dovrebbe tenere in considerazione durante la progettazione di un indice.

1. Dimensioni del tavolo

La prima domanda che uno sviluppatore di database deve porsi prima di creare un indice è se la tabella è sufficientemente grande o meno per utilizzare in modo efficiente gli indici. Se la dimensione della tabella è piccola, il motore di SQL Server può eseguire la scansione dell'intera tabella più rapidamente rispetto alla ricerca nella tabella tramite un indice. Gli indici in questo caso non hanno alcuna utilità e creano un sovraccarico durante l'esecuzione delle operazioni di database.

2. Tipi di colonne

Gli indici devono essere creati su una colonna della chiave primaria o su qualsiasi colonna che contenga valori univoci e che abbia un vincolo NOT NULL. Inoltre, è consigliabile creare indici su colonne numeriche poiché le colonne numeriche tendono ad avere valori più univoci rispetto alle colonne non numeriche. Una progettazione scadente dell'indice del database utilizza indici su colonne che hanno pochissime voci univoche e possono comportare query che richiedono molto tempo.

Si consideri una tabella denominata Pazienti che contiene centinaia di migliaia di record. La tabella Pazienti conterrebbe una colonna denominata "Sesso" che può avere solo due valori univoci "Maschio" e "Femmina". Se crei un indice sulla “Colonna Sesso”, i record saranno ordinati in ordine alfabetico crescente o decrescente.

Quindi, se hai un milione di record nella tabella Pazienti e il numero di pazienti maschi e femmine è uguale, nell'indice il primo mezzo milione di record avrà un genere "Femmina" e il secondo mezzo milione avrà un genere "Maschio". Ora, se si desidera cercare una femmina che esiste nella riga 490.000 dei record femminili, SQL Server Engine dovrà eseguire la scansione di 490.000 record. D'altra parte, con valori numerici univoci, la ricerca può essere estremamente veloce poiché gli indici di SQL Server sono archiviati sotto forma di alberi B + e quindi i valori numerici nei nodi dell'albero possono velocizzare le operazioni del database.

3. Numero di indici

Ufficialmente puoi creare un indice cluster e tutti gli indici non cluster che desideri per ogni tabella del database. Tuttavia, è una buona progettazione dell'indice del database creare un indice cluster e solo un numero limitato di indici non cluster assolutamente necessari. La creazione di troppi indici non in cluster può effettivamente rallentare le operazioni di aggiornamento e inserimento perché quando un record viene aggiornato o inserito e viene modificato un valore di colonna, tutti gli indici associati devono essere aggiornati.

Si consideri uno scenario in cui abbiamo due indici non raggruppati, il primo indice ordina i record per età e il secondo indice ordina i record per sesso ed età.

Ecco il primo indice:

Ed ecco il secondo:

Ora, se per qualche motivo un record con 40 anni deve essere aggiornato a 15 anni, allora il primo indice dovrà essere aggiornato per spostare il record dalla 7a posizione (40) alla seconda posizione in modo da mantenere l'indice ordinato. Allo stesso modo nel secondo indice, il record nel 4° indice verrà spostato nel secondo indice. Deve aver luogo un sacco di rimescolamento. Pertanto è opportuno mantenere il numero di indici al minimo per le colonne che vengono regolarmente aggiornate quando si pensa alla progettazione degli indici del database. Inoltre, una colonna non deve essere utilizzata in più indici non cluster.

4. Posizione di archiviazione degli indici

Il percorso di archiviazione di un indice può influire sulle prestazioni delle query che utilizzano l'indice e quindi fa anche parte di una buona progettazione dell'indice del database. Per impostazione predefinita, un indice cluster viene archiviato nello stesso filegroup della tabella su cui viene creato l'indice. Per gli indici non in cluster, l'indice può essere archiviato nello stesso filegroup o in diversi filegroup che si estendono su più unità disco. Le prestazioni delle query degli indici non in cluster possono essere notevolmente migliorate archiviando gli indici non in cluster su più unità disco. Ciò è dovuto al fatto che le prestazioni di input/output della query verranno migliorate a causa della distribuzione dei dati su diverse aree dell'unità.

La posizione di archiviazione predefinita degli indici può essere modificata anche specificando un valore per l'opzione FILLFACTOR. Poiché gli indici sono archiviati fisicamente sotto forma di B+ Trees, i dati dell'indice sono archiviati su pagine foglia. Con l'opzione FILLFACTOR, puoi impostare la percentuale delle pagine a livello di foglia da riempire. Ad esempio, se imposti il ​​valore di FILLFACTOR su 70%, solo il 70% dello spazio totale della pagina a livello di foglia verrà riempito dai dati dell'indice. Il restante 30% sarà lasciato per la crescita automatica dei dati dell'indice in futuro.

5. Tipi di indici

Un'altra considerazione estremamente importante nella progettazione dell'indice di database è il tipo di indice da utilizzare. In un articolo precedente (aggiungere un collegamento all'articolo "Quando utilizzare l'indice cluster o non cluster") ho spiegato la differenza tra indici cluster e non cluster. Ho anche spiegato cosa sono e come possono essere utilizzati. La decisione se scegliere un indice cluster o non cluster è cruciale e dovrebbe essere attentamente ponderata.

I seguenti punti dovrebbero essere tenuti a mente mentre si decide quale tipo di indice scegliere.

1. Per le colonne utilizzate nelle query SELECT/JOIN/GROUP BY/BETWEEN, utilizza gli indici cluster.
2. Utilizza indici non cluster per le colonne in cui desideri recuperare i valori solo da quella specifica colonna e non dalle altre colonne della stessa riga. Le query SELECT che recuperano più record utilizzando un indice non cluster possono essere lente perché il motore di SQL Server esegue prima la ricerca nei valori della colonna su cui viene creato l'indice e quindi utilizzando il riferimento di riga per il valore della colonna, vengono recuperati i record dalle tabelle del database effettive .
3. Per le colonne che spesso subiscono operazioni INSERT e UPDATE, utilizzare un indice non cluster. Assicurati di non utilizzare una colonna in più indici non cluster poiché ciò può rallentare le query di aggiornamento. Gli indici cluster possono essere lenti per le operazioni INSERT/UPDATE perché è necessario aggiornare l'intera riga anziché un solo valore di colonna, come nel caso degli indici non cluster.
4. Poiché puoi creare un solo indice cluster, nel caso in cui siano necessari più indici, utilizza indici non cluster. Tuttavia, se lo spazio su disco è un problema importante, mantieni il numero di indici non in cluster al minimo.

Altre considerazioni

Sebbene queste siano le cinque parti più importanti della progettazione dell'indice di database, non sono tutto. È importante specificare l'ordine corretto delle colonne negli indici. Come regola generale, le colonne utilizzate per il processo decisionale nelle clausole WHERE e condizioni come maggiore di (>), minore di (<) ecc., devono essere poste prima delle colonne non coinvolte in queste clausole. In caso di più colonne nella clausola WHERE, i nomi di colonna più distintivi dovrebbero essere menzionati per primi nella definizione dell'Indice.

Oltre alla progettazione dell'indice del database, anche la progettazione della query svolge un ruolo importante nell'uso efficiente della progettazione dell'indice. Per una manutenzione ottimizzata dell'indice invece di scrivere più query che operano su un numero ridotto di righe, prova a scrivere meno query che interessano un numero maggiore di righe della tabella.

Conclusione

Questo articolo spiega alcune delle principali considerazioni che uno sviluppatore di database deve tenere in considerazione quando esamina la progettazione dell'indice di database. L'articolo spiega anche la logica alla base di queste considerazioni e contiene ulteriori suggerimenti per garantire che la progettazione dell'indice del database sia efficiente.