Często używam SSMS do testowania moich wolnych procedur przechowywanych pod kątem brakujących indeksów. Ilekroć widzę „brakujący indeks (Impact xxx)”, moją reakcją kneejerk jest po prostu utworzenie nowego indeksu. Powoduje to szybsze zapytanie za każdym razem, o ile wiem.
Czy jest jakiś powód, dla którego nie powinienem tego kontynuować?
Odpowiedzi:
Wiele powodów.
Jednym z największych, jakie mogę wymyślić, jest to, że brakujące indeksy DMV nie uwzględniają istniejących indeksów.
Przykład:
Masz stolik z
ColA, ColB, ColC.Obecnie masz indeks na
ColA. Brakujący indeks DMV zasugeruje dodanie indeksu(ColA, ColB). Może to być poprawne, ale mądrą rzeczą jest dodanieColBdrugiego klucza do istniejącego indeksu. W przeciwnym razie masz zdublowany zasięg i zmarnowane miejsce i koszty ogólne.Podobnie, jeśli masz indeks
ColB INCLUDE (ColA), może sugerować indeks naColB INCLUDE (ColC). Znowu mądrą rzeczą jest dodanieColCdo listy dołączeń w istniejącym indeksie.Sugerowane indeksy mają bardzo wąski widok - patrzą tylko na jedno zapytanie lub pojedynczą operację w ramach jednego zapytania. Nie biorą pod uwagę tego, co już istnieje, ani innych wzorców zapytań.
Nadal potrzebujesz myślącego człowieka, aby przeanalizować ogólną strategię indeksowania i upewnić się, że struktura indeksu jest wydajna i spójna.
Gdyby nie było problemów z dodawaniem wszystkich sugerowanych indeksów, nie byłoby nawet potrzeby ich sugerowania - byłyby one wdrażane automatycznie.
źródło
duplicate index scriptslub coś podobnego, istnieje wiele zasobów do śledzenia tych rzeczy. Zarządzam większością własnych indeksów i dobrze o tym wiem, ale od czasu do czasu znajduję duplikaty.Zalecam ostrożne stosowanie tej techniki dostrajania, ponieważ zauważyłem, że brakujące sugestie indeksów pojawiające się w planach zapytań są konsekwentnie mniej niezawodne, ponieważ zapytania i schematy DB stają się coraz bardziej złożone. Wynika to z różnych powodów z mojego doświadczenia:
1) „Poprawa procentowa” może być daleka od wszystkich oprócz najprostszych zapytań / najbardziej oczywistych indeksów, w końcu jest to tylko szacunek i nie wynika z faktycznych kosztów ani faktycznych liczby wierszy podczas uruchamiania zapytania. Widziałem, że koszty zapytania rosną po wdrożeniu sugerowanego indeksu lub nawet się nie przyzwyczajają i plan pozostaje taki sam.
2) Sam plan zapytań nie jest optymalny, ani ze względu na konstrukcję zapytania (złączenia i gdy klauzula nie jest zoptymalizowana itp.), Albo szacunki liczby wierszy są wyłączone z powodu brakujących / nieaktualnych statystyk. Indeksowanie do brutalnie złego planu zapytań jest często najlepszym rozwiązaniem wspomagającym zespół z jedynie stopniową poprawą wydajności.
3) Być może nie widzisz całego obrazu. Jest to szczególnie prawdziwe, gdy używa się tylko planu graficznego i nie przegląda się XML, aby sprawdzić, czy zasugerowano więcej niż jeden brakujący indeks. Ten pokazany jako pierwszy w planie graficznym niekoniecznie ma największy wpływ na zapytanie.
4) Zetknąłem się również z wieloma przykładami nowych indeksów sugerowanych podczas modyfikacji istniejącego indeksu. Zobacz inne odpowiedzi tutaj dotyczące tego punktu, są one na miejscu, nie muszę już więcej omawiać.
Używam tylko brakujących sugestii indeksu jako punktu wyjścia podczas pracy z nieznanym zapytaniem / środowiskiem, aby zobaczyć, gdzie szukać głębiej. Uzyskałem lepsze wyniki, patrząc na operatorów w planie (głównie wyszukiwania / skany / łączenia) i sprawdzając podpowiedź lub okno właściwości, aby zobaczyć, które kolumny są zaangażowane, i używając tego do określenia kandydatów indeksu do przetestowania pod kątem poprawy.
źródło
Istnieje wiele powodów, głównie - wiedząc, jak indeksy działają i są przechowywane - zawsze będziesz tworzyć indeks lepiej, a przynajmniej - nie gorzej, że sugestie SSMS
źródło