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.