Niewykorzystane indeksy Najlepsze praktyki

Na podstawie tego zapytania, jeśli widzę małą liczbę odczytów (bardzo blisko 0 lub 0, np. 1 lub 2) oraz dużą lub umiarkowaną liczbę aktualizacji użytkowników (nie mogłem znaleźć wstawek ani usunięć przy tym zapytaniu) z dużą liczbę wierszy, teoretycznie powinienem usunąć indeks.

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

Chcę tutaj sprawdzić dokładność tego założenia. Na przykład indeks, który istnieje od ponad roku, ale nigdy nie został odczytany, ale wysoce zaktualizowany, wydaje się, że posiadanie go byłoby złym pomysłem. Czy istnieje scenariusz, w którym to założenie jest nieważne?

Ten DMV utrzymuje statystyki tylko od ostatniego restartu SQL Server; widok zostaje całkowicie wymazany i wszystko zaczyna się od zera.

Co ważniejsze, wiersze w tym widoku dla dowolnego określonego indeksu są usuwane po odbudowaniu tego indeksu (ale nie przy reorganizacji). Jeśli wykonujesz regularną konserwację indeksu, przydatne może być przejrzenie dzienników konserwacji i sprawdzenie, czy któryś z indeksów, który chcesz usunąć, mógł zostać niedawno odbudowany.

Zatem podejmowanie decyzji na podstawie niskich odczytów od ostatniego restartu, kiedy ostatni restart mógł dotyczyć wtorkowych aktualizacji z zeszłego tygodnia lub wczorajszego dodatku Service Pack, może nie być mądry. Lub podczas wykonywania konserwacji indeksu od ostatniej odbudowy. Może istnieć raport, który jest uruchamiany tylko raz w miesiącu, raz na kwartał lub raz w roku i jest prowadzony przez ważną i niecierpliwą osobę.

Ponadto może istnieć indeks czegoś, co wydarzy się w przyszłości, o czym nie wiesz - na przykład seria raportów przygotowywanych na sezon podatkowy.

Moja rada to:

Użyj DMV, aby zidentyfikować indeksy kandydatów do usunięcia , ale nie podejmuj tej decyzji w dymku - musisz wykonać czynności przygotowawcze, aby ustalić, dlaczego indeks może istnieć przed jego upuszczeniem, nawet jeśli wygląda na to, że nie jest aktualnie używany .

Tak, widok ma statystyki tylko od ostatniego restartu. Aby to złagodzić, skonfigurowałem zadanie, które uruchamiało zapytanie takie jak to, które publikowałeś co miesiąc rano, zanim nasze okno konserwacji zaczęło rejestrować informacje co miesiąc przed ponownym uruchomieniem serwera. To pozwoliło mi cofnąć się w czasie i spojrzeć na trendy w czasie. Miałem też drugie zapytanie, w którym szukałem potencjalnie brakujących indeksów.

Inną rzeczą do rozważenia jest to, jakie inne indeksy znajdują się w tabeli. Może się nie przyzwyczaić, ponieważ w większości lub całkowicie jest duplikatem innego indeksu. Tak. Serwer SQL pozwala tworzyć dwa różne, ale identyczne indeksy, dzięki czemu może być całkowicie redundantny.

Możesz także sprawdzić, jaki może być plan kwerend dla zapytania, które korzystało z tego indeksu, gdyby ten indeks został usunięty. Czy użyłby innego indeksu, czy też prawdopodobnie musiałby wrócić do pełnego skanowania tabeli.

Indeksy są tak samo sztuką, jak nauką, ponieważ naprawdę trudno jest wiedzieć wszystko o tym, co można uruchomić, i tak czy inaczej często się zmienia.