Eliminazione di indici inutilizzati: valutazione dei pericoli imprevisti

Abbiamo un database molto grande con centinaia di indici inutilizzati secondo le statistiche DMV, che si sono accumulate dall'ultimo riavvio del server a luglio. Uno dei nostri DBA ha rilasciato le seguenti dichiarazioni cautelative, che per me non hanno senso:

1. Prima di rilasciare un indice, è necessario accertarsi che non imponga un vincolo di unicità, poiché Query Optimizer potrebbe aver bisogno di questo indice per esistere.
2. Ogni volta che viene creato un indice, anche le statistiche relative a tale indice vengono create in SQL Server. Una query potrebbe non utilizzare l'indice ma potrebbe utilizzare le sue statistiche. Quindi potremmo imbatterci in una situazione, dopo aver lasciato cadere un indice una prestazione della query particolare va davvero male. SQL Server non mantiene le statistiche di utilizzo delle statistiche. Sebbene nel nostro database sia abilitata la funzione "Crea automaticamente statistiche", non so quali parametri devono essere soddisfatti internamente prima che Query Optimizer crei le statistiche mancanti.

Per quanto riguarda il n. 1, mi sembra che SQL Server farebbe effettivamente una ricerca sull'indice per determinare l'univocità prima che venga effettuato un inserimento / aggiornamento e, pertanto, l'indice non mostrerebbe come non utilizzato.

Per quanto riguarda il n. 2, è davvero possibile?

A proposito, quando dico che un indice non viene utilizzato, intendo nessuna ricerca e nessuna scansione.

Le preoccupazioni del tuo DBA sono entrambe valide.

Per quanto riguarda il n. 1, mi sembra che SQL Server farebbe effettivamente una ricerca sull'indice per determinare l'univocità prima che venga effettuato un inserimento / aggiornamento e, pertanto, l'indice non mostrerebbe come non utilizzato.

La garanzia di unicità può essere utilizzata dall'ottimizzatore per decidere quali trasformazioni logiche o operazioni fisiche possono essere utilizzate per ottenere risultati corretti. Il fatto che l'ottimizzatore faccia affidamento su una garanzia di unicità per, ad esempio, trasformare un'aggregazione o scegliere un join di unione uno-a-molti, non si rifletterà nelle statistiche sull'utilizzo dell'indice, a meno che l'indice non sia anche fisicamente accessibile nel piano di esecuzione finale . Bisogna quindi fare molta attenzione a rimuovere (o disabilitare) qualsiasi indice o vincolo univoco.

Per quanto riguarda il n. 2, è davvero possibile?

Sì, è possibile che l'ottimizzatore utilizzi le statistiche associate a un indice senza il piano di esecuzione finale che prevede l'accesso tramite tale indice. I processi di caricamento di statistiche "interessanti", il calcolo di stime di cardinalità e la produzione di un piano di esecuzione finito sono attività abbastanza indipendenti.

Se si elimina l'indice, le statistiche dell'indice associate verrebbero rimosse, il che potrebbe influire sulla qualità del piano alla successiva ricompilazione dell'istruzione. Le statistiche dell'indice possono essere utilizzate in un calcolo di stima della cardinalità su cui si basa il piano finale, anche se l'indice non è fisicamente presente nel piano finale.

Il tuo DBA conosce le sue cose.

Niente di tutto ciò dovrebbe significare che gli indici apparentemente inutilizzati non dovrebbero mai essere rimossi. Sto semplicemente dicendo che le preoccupazioni del tuo DBA sono valide e dovresti pianificare di conseguenza la modifica con esse, con test appropriati e un piano di recupero. Nella mia esperienza, il punto n. 1 ha maggiori probabilità di essere problematico rispetto al n. 2, ma non ho modo di sapere se ciò si applica alla tua situazione.