Immaginiamo di dover cercare una parola in un libro. L’azione più naturale (la prima che ci viene in mente) è quella di andare nell’indice analitico dove possiamo facilmente trovare le pagine nelle quali appare la parola che stiamo cercando, perché le parole in un indice sono ordinate alfabeticamente. Possiamo quindi leggere le pagine indicate dall’indice e trovare tutte le informazioni associate alla parola cercata.
Cosa succederebbe se il nostro libro non avesse indici ? Avremmo dovuto leggere l’intero libro, dall’inizio, pagina per pagina, per cercare tutte le occorrenze della parola che desideriamo trovare.
Anche SQL Server applica questa stessa logica quando ricerca per un valore di un attributo. Indicizzando l’attributo SQL Server potrà eseguire un’index seek, in alternativa l’engine sarà costretto a leggere tutte le pagine eseguendo l’operazione che viene chiamata table scan.
Potremmo quindi avere la tentazione di indicizzare tutti i possibili attributi di una tabella! In ogni caso SQL Server dovrà mantenere aggiornati tutti gli indici che abbiamo deciso di creare… più indici decideremo di creare più lenti saranno i comandi di update.
E se un attributo fosse doppiamente indicizzato ? In questo caso SQL Server sarà costretto ad aggiornare due indici, organizzati in strutture B-Tree letteralmente identiche, senza trarre alcun beneficio da una delle due.
La stored procedure dbo.usp_drop_double_more_index, illustrata nella figura seguente, permette di individuare ed eliminare i casi di doppia (tripla, ...) indicizzazione dei medesimi attributi.
_1.PNG)