Wprowadzenie
Zapytanie SQL opisuje oczekiwany wynik, a nie sposób uzyskania wyniku. Zestaw konkretnych kroków, które serwer musi wykonać, aby zwrócić wynik, nazywa się planem wykonania zapytania. Plan jest budowany przez optymalizator. Wybór planu wpływa na szybkość wykonania, co czyni go jednym z najważniejszych elementów analizy problemu z wydajnością zapytania.
Plan wykonania zawiera operatory i ich właściwości, które są ze sobą powiązane w formie struktury drzewiastej. Każdy operator odpowiada za odrębną operację logiczną lub fizyczną. Wszystkie razem zapewniają wynik opisany w tekście zapytania. Wewnątrz drzewa operatory są reprezentowane przez obiekty klasy w pamięci SQL Server. Użytkownicy serwera (czyli Ty i ja) widzą opis wygenerowany w formacie XML z określonym schematem, który jest wyświetlany graficznie przez środowisko SQL Server Management Studio (SSMS).
Istnieje wiele różnych operatorów planów i jeszcze więcej właściwości. Poza tym od czasu do czasu pojawiają się nowe. Ten artykuł nie odważy się opisać wszystkich możliwych operatorów. Zamiast tego chciałbym podzielić się najciekawszymi dodatkami w tym temacie i przypomnieć kilka starych, ale przydatnych elementów.
Wersja serwera
Czasami na forach można znaleźć prośby o wersję serwera, nawet jeśli plan zapytań jest podany w odpowiednim formacie (XML). Zamiast tego możesz zaoszczędzić czas i otworzyć plan wykonania jako XML. A pierwszy element opisujący plan pokaże wersję serwera we właściwości Build.
Ta metoda nie pozwala na odzyskanie pełnych informacji o edycji serwerowej, ale w większości przypadków wystarczy zrozumieć, z czym mamy do czynienia.
Liczba wierszy tabeli
Drugie częste pytanie to „Ile wierszy zawiera Twoja tabela?”. Informacje te można również pobrać z planu zapytań (od wersji serwera 2008). W tym celu musimy wybrać operatora dostępu do danych (Scan lub Seek) danej tabeli i spojrzeć na TableCardinality własność. Jest jeszcze jedna interesująca właściwość, Szacowany rozmiar wiersza do określenia rozmiaru wiersza i przybliżonej oceny rozmiaru tabeli lub indeksu (zakładając, że tabela nie jest skompresowana).
Chciałbym zauważyć, że nie jest to rzeczywista liczba wierszy w tabeli, ale dane ze statystyk obiektów. Jednak te dane są podstawą decyzji podejmowanych przez optymalizator podczas budowania zapytania.
Kontekst
Plan zapytania zapisuje godne uwagi ustawienia SET, dla których został zbudowany. Aby wyświetlić ustawienia, musisz wybrać element główny w planie i rozwinąć Ustaw opcje własność. Na przykład możemy dowiedzieć się, czy plan został zbudowany przy użyciu ARITHABORT opcja włączona (różnica tego ustawienia często prowadzi do dwóch różnych planów i sytuacji ze złym podsłuchiwaniem parametrów).
Liczba procesorów
Możemy pobrać liczbę procesorów dostępnych dla optymalizatora. W tym celu musimy otworzyć OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism parametru w tym samym elemencie głównym i pomnóż go przez 2. Jeśli dostępny jest tylko jeden procesor, nie ma potrzeby mnożenia.
Dostępne są 2*2 =4, 4 procesory. Rzeczywiście, mam 4-rdzeniowy procesor na moim komputerze i wszystkie 4 rdzenie są dostępne dla serwera. Te informacje mogą pomóc w wykryciu maszyny, na której wygenerowano plan.
Wersja szacowania kardynalności
Począwszy od programu SQL Server 2014, udostępniono kilka wersji programu Cardinality Estimator (RU). Mechanizm ten wpływa na większość decyzji podejmowanych przez optymalizatora podczas wyboru planu. Wersję narzędzia szacowania kardynacji można pobrać z CardinalityEstimationModelVersion właściwość operatora głównego.
- 0 – Serwer SQL <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Czas wykonania zapytania i czas oczekiwania
Od wersji SQL Server 2016 SP1 rzeczywisty plan zapytań zawiera informacje o czasie wykonania i czasie procesora. Aby pobrać te dane, musisz rozwinąć QueryTimeStats w elemencie głównym i wyświetlić wartości CpuTime i ElapsedTime . Nie musimy włączać zbierania czasu wykonania ani pytać „jak długo wykonywane było zapytanie?” już – wszystkie te informacje są zawarte w planie.
Drugim znaczącym ulepszeniem jest 10 najdłuższych czasów oczekiwania podczas wykonywania zapytania. W tym celu musimy rozwinąćWaitStats właściwość w elemencie głównym. Ten dodatek pozwala uzyskać dokładniejsze przyczyny powolnego wykonywania zapytań i znacznie upraszcza diagnostykę.
Typy parametrów
Lista parametrów właściwość, która zawiera listę parametrów użytych w zapytaniu, istniała w planie dawno temu. Jednak od wersji SQL Server 2016 SP1 Typ danych parametrów właściwość została dodana do definicji parametru. Ta właściwość przechowuje typ danych parametru. Może to być przydatne do zrozumienia problemów z konwersją typu.
Liczba odczytanych wierszy i szacowana liczba wierszy do odczytania
Plan wykonania zawiera dwie bardzo ważne właściwości, Rzeczywistą liczbę rzędów i Szacowaną liczbę rzędów. Te właściwości zawierają informacje o liczbie wierszy zwróconych przez operator odczytu danych, ale nie o liczbie wierszy, które faktycznie odczytał. Właściwości Liczba odczytanych wierszy i Szacowana liczba wierszy do przeczytania odpowiadają na to pytanie i umożliwiają pobranie liczby wierszy, które serwer faktycznie przeczytał lub zamierza odczytać. Właściwość ActualRowsRead (liczba odczytanych wierszy w SSMS) jest dostępna od SQL Server 2012 z dodatkiem SP3, 2014 z dodatkiem SP2, 2016 z dodatkiem SP1. EstimatedRowsRead (Szacowana liczba wierszy do odczytania w SSMS) jest dostępna od SQL Server 2016 SP1.
Statystyki we/wy i czas wykonania operatora
Istnieje kilka bardzo przydatnych właściwości wprowadzonych w SQL Server 2016, 2014 SP2 i dostępnych w rzeczywistym planie zapytań. Są to metryki we/wy (jeśli operator ma we/wy) — rzeczywiste statystyki we/wy, metryki czasu procesora i czasu wykonania — statystyki czasu rzeczywistego i metryki pamięci (od 2016 SP1, jeśli operator wymaga pamięci).
Właściwości zawierają następujące nowe metryki, które można podzielić na wątki w przypadku planu równoległego:
- Rzeczywiste Elapsedms
- Rzeczywiste procesory
- Rzeczywiste skanowanie
- Rzeczywiste odczyty logiczne
- RzeczywisteOdczytyFizyczne
- Rzeczywiste odczyty z wyprzedzeniem
- RzeczywisteLobLogicalReady
- RzeczywisteOdczytyLobFizyczne
- Rzeczywiste odczyty z wyprzedzeniem
- InputMemoryGrant
- OutputMemoryGrant
- Wykorzystana pamięćGrant
Jak widać z powyższej listy, możesz pobrać wyczerpujące informacje o wykonaniu dowolnego operatora, zużytych IO i pamięci. W ostatnich wersjach programu SSMS te metryki są reprezentowane w oknie właściwości. Jeśli używasz starej wersji SSMS, możesz je odzyskać, otwierając plan jako XML. Moim zdaniem teraz jest wszystko, aby pokazać procenty nie według szacowanego kosztu, ale według rzeczywistych zasobów (stworzyłem sugestię w Connect. Więc jeśli podoba ci się ten pomysł, zagłosuj na niego).
Informacje o włączonych flagach śledzenia
Flagi śledzenia w SQL Server to specjalne „przełączniki” z domyślnego zachowania serwera na inne zachowanie. Począwszy od SQL Server 2014 z dodatkiem SP2 i 2016 z dodatkiem SP1, informacje o włączonych flagach śledzenia są dostępne we właściwości TraceFlags określonego elementu. Może zawierać do 100 jednocześnie włączonych flag w momencie tworzenia zapytania.
Informacje o wycieku danych do tempdb
Niektóre operatory planu, na przykład sortowanie lub dopasowanie skrótu, wymagają pamięci podczas wykonywania zapytania. Jednak wielkość pamięci jest obliczana w momencie kompilacji. Z różnych powodów (np. błędna ocena domniemanej liczby lub wierszy) pojemność pamięci może zostać błędnie obliczona. Jeśli przydzielono mniej pamięci niż jest to wymagane do wykonania, serwer będzie musiał rozlać dane do tempdb. Spowalnia wykonywanie zapytania. Ostrożność wobec takiej sytuacji została wprowadzona w serwerze 2012, ale od wersji SQL Server 2012 SP3, 2014 SP2, 2016 rozszerzono informacje diagnostyczne i teraz obejmują one ilość danych rozlanych i odczytanych. Możesz więc ocenić problem i podjąć odpowiednie kroki.
Wniosek
Plan wykonania zawiera wiele przydatnych informacji, rzeczywisty plan zapytań zawiera jeszcze więcej informacji, a rzeczywisty plan zapytań w ostatnich wersjach SQL Server to tylko kopalnia przydatnych informacji. Ten artykuł nie ma na celu nauczenia kogoś analizowania planów zapytań. Zamiast tego rozważyłem najciekawsze nieruchomości w planie, w tym nowe i stare, ale niedoceniane. Mam nadzieję, że ten artykuł pomoże ci następnym razem, gdy będziesz musiał przeanalizować wydajność zapytania.
Artykuł został przetłumaczony przez zespół Codingsight za zgodą autora.
Przydatne narzędzie:
dbForge Query Builder dla SQL Server – pozwala użytkownikom szybko i łatwo tworzyć złożone zapytania SQL za pomocą intuicyjnego interfejsu wizualnego bez ręcznego pisania kodu.
