SQL Server:
covered index

In questo breve articolo discuteremo il concetto di Covered Index e di come esso può essere utilizzato per migliorare le performance di query troppo lente. A volte creare un indice sulla foreign key o sulle colonne da filtrare potrebbe non bastare. Infatti la presenza di altre colonne (anche se presenti soltanto nella select) potrebbe spingere il piano di esecuzione a non utilizzare gli indici non clustered creati e a dover effettuare dunque delle costose ricerche.

Quando creiamo un indice non clustered su una colonna, Sql Server salverà nelle foglie di tale indice soltanto un puntamento alla riga completa (costituito generalmente dalla chiave della tabella). Se nella select sono presenti altre colonne, Sql server dovrà usare questo puntamento per recuperarle.

Tramite la sintassi INCLUDE, possiamo aggiungere tali colonne direttamente nelle foglie dell’indice, senza modificarne la struttura, ed evitare così il costo delle operazioni di recupero!

Nella foto il codice d’esempio utilizzato:

  • con la prima query abbiamo creato una tabella temporanea contenente una colonna con un progressivo da 1 a 50000 e una colonna con sempre il valore ‘a’;
  • nella seconda query costruiamo un’indice non clustered sul progressivo;
  • la terza query e il relativo piano di esecuzione, mostrano come sia necessaria l’operazione di RID lookup per recuperare i dati della colonna2, non presente nell’indice creato in precedenza;
  • aggiungendo questa colonna alle foglie di un nuovo indice tramite la sintassi INCLUDE (quarta query), l’operazione di RID lookup non sarà più necessaria per la quinta query, con un conseguente miglioramento delle performance.

Avete mai creato indici con l’INCLUDE? Conoscete le limitazioni sui tipi di dato e quando possono portare a deterioramenti delle performance?
covered index performance della query

Source