Strojenie wydajności zapytania

Kiedy zakończysz pisanie zapytania / przechowywanego proc / funkcji, jaki jest najbardziej pouczający sposób szybkiego uzyskania niektórych parametrów wydajności? Czy uruchamiasz zapytanie i przeglądasz aktualny plan wykonania? Jeśli tak, to czego szukasz? Oczywiście skany tabeli / indeksu są hitami, ale co jeszcze?

W celu szybkiej oceny pobierz plan wykonania z SSMS i przejdź do Eksploratora Planów .

• Przejrzyj najdroższe operacje pod kątem nieoczekiwanych. Sortuje, stoły robocze, nieodpowiednie operatory łączenia (np. Zagnieżdżona pętla, w której oczekujesz scalenia lub skrótu).
• Spójrz na liczby wierszy na każdym etapie planu, czy są one zasadniczo w zakresie, którego się spodziewałeś?
• Spójrz na rzędy szacunkowe a rzeczywiste. Jeśli Twoje rzeczywiste wartości są bliskie szacunkom, bardziej prawdopodobne jest, że masz dobry plan. Jeśli występują duże różnice, dowiedz się, dlaczego (brakujące i / lub nieaktualne statystyki).
• Oceń potencjał problemów z wąchaniem parametrów. Poszukaj obszarów, w których liczność może się różnić, i przetestuj względem szeregu parametrów wejściowych.

Wiele darmowych materiałów referencyjnych, plany wykonania SQL Server Granta Fitchleya to dobry początek. Zauważyłem również, że posty na blogu i ebooka Joe Changa dotyczące planu wykonania są bardzo przydatne.

Przeważnie wszystko, co robię, to po prostu uruchomić kwerendę i dowiedzieć się, jak wykonuje się ona w stosunku do rzeczywistych danych. Jeśli jest problem, sprawdzam plany wykonania.

Jeśli chodzi o plany wykonania, Brad McGehee ma ciekawy artykuł na ten temat.

W nim mówi:

Jeśli w planie wykonania zobaczysz którekolwiek z poniższych elementów, powinieneś rozważyć ich znaki ostrzegawcze i zbadać je pod kątem potencjalnych problemów z wydajnością. Każdy z nich jest mniej niż idealny z punktu widzenia wydajności.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Nie zawsze można ich uniknąć, ale im więcej można ich uniknąć, tym większa będzie wydajność kwerendy.

SET STATISTICS IO ON

Zasadniczo „liczba odczytów logicznych” powinna być jak najniższa. Kilka stron dotkniętych w celu wykonania zapytania, tym lepszy plan, ponieważ będzie (zazwyczaj) szybszy, mniejszy wpływ na procesor, pamięć RAM i operacje wejścia / wyjścia dysku.

Pomoże to w zmianie indeksów lub przefaktorowaniu SQL. Patrząc na „czas realizacji w milisekundach” będzie się różnił nawet w przypadku tego samego SQL i planu zapytań - logiczne odczyty pozostaną spójne dla każdego planu zapytań.

Również „fizyczne odczyty” powinny być bardzo niskie (i być zerowe i pozostać zerowe dla kolejnych wykonań). Jeśli tak się nie stanie, sprawdź zużycie pamięci SQL Server (żywotność strony itp.).