Determinare che gli indici su una tabella non sono utilizzati

Ho eseguito questo script per cercare di trovare indici estranei

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

So che quando last_user_seek / scan / lookup sono tutti nulli, che nessun utente ha utilizzato l'indice dall'ultimo riavvio. Ma mi chiedo quali system_scans / lookups / seeks ... sono? Perché su un certo tavolo ne ho trovati 5 che non avevano attività dell'utente, ma uno aveva attività di sistema 10 giorni fa. Qualcuno ha qualche idea su quali scansioni / ricerche / ricerche di sistema potrebbero essere? Queste tabelle sembrano davvero troppo indicizzate e mi piacerebbe tagliare il grasso.

Manutenzione dell'indice (ricostruzione / riorganizzazione) e attività DBCC CHECKDB molto probabilmente, possibilmente aggiornamenti delle statistiche. Qualche manutenzione programmata è stata configurata?

Se non vi è alcun accesso dell'utente, bin loro. Basta essere consapevoli del lasso di tempo in cui si decide che non vengono più utilizzati. Esistono attività di reporting settimanali o mensili, ad esempio?

Mentre stai cercando, cerca anche gli indici duplicati .

Modifica: per quanto riguarda il collegamento SSC

Da una rapida scansione attraverso il thread, sembra che la gente SSC abbia avuto pensieri simili. Stanno tuttavia prendendo una posizione più cauta sul possibile uso "occasionale" di questi indici, assumendo la posizione in cui qualcuno li ha messi lì per una ragione, un argomento perfettamente ragionevole. L'argomentazione contraria è che troppo spesso è esattamente il contrario, qualcuno li ha messi lì perché pensavano che fosse la cosa giusta da fare, ma per mancanza di comprensione o mancanza di test, non lo era.

Ho riportato un paio di sistemi dal limite, facendo nient'altro che far cadere indici inutilizzati e duplicati. L'indicizzazione eccessiva può causare caos.

È il tuo sistema, devi capire e soppesare i rischi di lasciare in posizione questi indici o di farli cadere. Se decidi di procedere con il rilascio, documenta ciò che fai, perché lo stai facendo, scrivi gli indici e pubblicalo a tutte le parti interessate.

Glenn Berry ha scritto degli ottimi script per aiutarti a trovare gli indici mancanti. Ti suggerisco di usare i suoi script che ti tolgono dal lavoro alcune ipotesi. Questi script non sono solo alla ricerca di null / 0 ricerche / scansioni / ricerche da parte dell'utente, ma anche alla ricerca di indici che presentano una grande inclinazione tra l'attività di lettura e l'attività di scrittura, con la conseguente possibile riduzione delle prestazioni complessive. Verificherei i suoi script - puoi iniziare su questo suo post .

Non sarei preoccupato per l'attività del sistema. Questo non è qualcosa che peggiorerà se si rimuovono gli indici, in effetti potrebbe essere l'attività che si verifica solo su quell'indice perché esiste. La cosa principale che ti interessa è l'attività di lettura dell'utente e l'attività di scrittura dell'utente e il bilanciamento.

Ricorda che gli indici forniscono anche informazioni utili allo Strumento per ottimizzare le query, anche se non vengono utilizzati. Ho fatto un bel po 'di cose sull'impatto dell'unicità, per esempio. Se rimuovi un indice univoco perché non ha ricerche o scansioni, potresti comunque influire negativamente sulle prestazioni.

Oltre a quanto affermato da tutti gli altri, gli indici rispetto alle colonne FK referenziate potrebbero non mostrare mai ricerche o scansioni, ma vengono utilizzati sotto le copertine.