Ustalanie, że indeksy w tabeli są nieużywane

Uruchomiłem ten skrypt, aby znaleźć dodatkowe indeksy

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’

Wiem, że gdy ostatnie szukanie_użytkownika / skanowanie / wyszukiwanie ma wartość NULL, żaden użytkownik nie używał indeksu od ostatniego restartu. Ale zastanawiam się, jakie są system_scans / lookups / seek…? Ponieważ w pewnej tabeli znalazłem 5, które nie miały aktywności użytkownika, ale jedna miała aktywność systemu 10 dni temu. Czy ktoś ma wgląd w to, jakie mogą być skany / próby / wyszukiwania systemu? Te tabele wydają się naprawdę przesadzone i chciałbym przyciąć tłuszcz.

Utrzymanie indeksu (przebudowa / reorganizacja) i aktywność DBCC CHECKDB najprawdopodobniej możliwe aktualizacje statystyk. Czy skonfigurowano zaplanowaną konserwację?

Jeśli nie ma dostępu użytkownika, bin je. Pamiętaj tylko o czasie, w którym zdecydujesz, że nie są już używane. Czy istnieją na przykład jakieś raporty tygodniowe lub miesięczne?

Podczas wyszukiwania możesz również znaleźć duplikaty indeksów .

Edycja: dotyczy linku SSC

Od szybkiego przejrzenia wątku wygląda na to, że ludzie SSC mieli podobne myśli. Zajmują jednak bardziej ostrożne stanowisko w sprawie możliwego „sporadycznego” wykorzystania tych indeksów, przyjmując stanowisko, że ktoś umieścił je tam z jakiegoś powodu, co jest całkowicie uzasadnionym argumentem. Kontrargumentem jest to, że zbyt często jest dokładnie odwrotnie, ktoś je tam umieścił, ponieważ uważali , że to właściwe, ale z powodu braku zrozumienia lub braku testowania, tak nie było.

Przywróciłem kilka systemów z krawędzi, nie robiąc nic poza upuszczeniem nieużywanych i zduplikowanych indeksów. Nadmierne indeksowanie może powodować chaos.

To twój system, musisz zrozumieć i zważyć ryzyko pozostawienia tych indeksów na miejscu lub ich upuszczenia. Jeśli zdecydujesz się na upuszczenie, udokumentuj, co robisz, dlaczego to robisz, skryptuj indeksy i publikuj je wszystkim zainteresowanym stronom.

Glenn Berry napisał kilka świetnych skryptów, które pomogą Ci znaleźć brakujące indeksy. Sugeruję użycie jego skryptów, które eliminują część zgadywanych zadań. Te skrypty nie tylko szukają zerowych lub zerowych wyszukiwań użytkowników / skanów / wyszukiwań, ale także szukają indeksów, które mają duże odchylenie między aktywnością odczytu i aktywnością zapisu, prawdopodobnie wciąż skutkując lepszą ogólną wydajnością po upuszczeniu. Sprawdziłbym jego skrypty - możesz zacząć od jego postu .

Nie martwiłbym się aktywnością systemu. To nie pogorszy się, jeśli usuniesz indeksy, w rzeczywistości może to być aktywność, która dzieje się tylko na tym indeksie, ponieważ istnieje. Najważniejsze, na czym Ci zależy, to aktywność związana z czytaniem i pisaniem oraz równoważenie tego.

Pamiętaj, że indeksy dostarczają także użytecznych informacji do Optymalizatora zapytań, nawet jeśli nie są używane. Na przykład zrobiłem sporo rzeczy na temat wpływu Unikatowości. Jeśli usuniesz unikalny indeks, ponieważ nie ma on żadnych wyszukiwań ani skanów, nadal możesz negatywnie wpłynąć na wydajność.

Oprócz tego, co wszyscy inni stwierdzili, indeksy w odniesieniu do odnośnych kolumn FK mogą nigdy nie pokazywać prób lub skanów, ale są używane pod przykryciem.