Best practice sugli indici non utilizzati

Sulla base di questa query, se vedo un basso numero di letture totali (molto vicino a 0 o 0, come 1 o 2) e un numero elevato o moderato di aggiornamenti utente (non sono riuscito a trovare inserimenti o eliminazioni con questa query) con un gran numero di righe, in teoria dovrei rimuovere l'indice.

SELECT DISTINCT
    OBJECT_NAME(s.[object_id]) AS ObjectName
       , p.rows TableRows
       , i.name AS [INDEX NAME]
       , (user_seeks + user_scans + user_lookups) AS TotalReads
       , user_updates UserUpdates
FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] 
        AND i.index_id = s.index_id 
    INNER JOIN sys.partitions p ON p.object_id = i.object_id
WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
       AND s.database_id = DB_ID()
       AND i.name IS NOT NULL
ORDER BY (user_seeks + user_scans + user_lookups) ASC

Voglio verificare in modo incrociato l'accuratezza di questa ipotesi qui. Ad esempio, un indice che esiste da oltre un anno ma non è mai stato letto, ma altamente aggiornato, sembra che sarebbe una cattiva idea avere. Esiste uno scenario in cui questo presupposto non è valido?

Questo DMV mantiene le statistiche solo dall'ultimo riavvio di SQL Server; la vista viene completamente cancellata e tutto inizia da zero.

Ancora più importante, le righe in questa vista per qualsiasi indice specifico vengono rimosse quando quell'indice viene ricostruito (ma non quando viene riorganizzato). Se si esegue una manutenzione periodica degli indici, potrebbe essere utile esaminare i registri di manutenzione e verificare se uno degli indici che si sta valutando di eliminare potrebbe essere stato ricostruito di recente.

Quindi, prendere decisioni basate su letture basse dall'ultimo riavvio, quando l'ultimo riavvio potrebbe essere stato per gli aggiornamenti di martedì della scorsa settimana o il service pack di ieri, potrebbe non essere saggio. O quando si esegue la manutenzione dell'indice, dall'ultima ricostruzione. Potrebbe esserci un rapporto che viene eseguito solo una volta al mese o una volta al trimestre o una volta all'anno ed è gestito da una persona importante e impaziente.

Inoltre, potrebbe esserci un indice per qualcosa che accadrà in futuro di cui non si è a conoscenza: una serie di rapporti in preparazione per la stagione delle imposte, diciamo.

Quindi, il mio consiglio è:

Usa il DMV per identificare gli indici candidati da rimuovere , ma non prendere quella decisione in una bolla - devi fare le legwork per determinare perché un indice potrebbe esistere prima di lasciarlo cadere, anche se sembra che non sia attualmente in uso .

Sì, la vista ha solo statistiche dall'ultimo riavvio. Per aiutare a mitigare che ho impostato un lavoro che eseguiva una query come quella che hai pubblicato mensilmente la mattina prima che la nostra finestra di manutenzione iniziasse a catturare le informazioni ogni mese prima che il server si riavviasse. Ciò mi ha permesso di tornare indietro e guardare le tendenze nel tempo. Ho anche avuto una seconda query che è stata eseguita alla ricerca di indici eventualmente mancanti.

Un'altra cosa da considerare è quali altri indici sono sul tavolo. Potrebbe non essere utilizzato perché è principalmente o completamente un duplicato di un altro indice. Sì. Il server SQL consente di creare due indici diversi ma identici in modo che sia completamente ridondante.

È inoltre possibile esaminare quale potrebbe essere il piano di query per una query che utilizzava quell'indice se tale indice fosse stato rimosso. Avrebbe un altro indice da utilizzare o dovrebbe probabilmente ricorrere a una scansione completa della tabella.

Gli indici finiscono per essere tanto l'arte quanto la scienza perché è davvero difficile sapere tutto su ciò che potrebbe essere gestito e finisce per cambiare spesso comunque.