Plany wykonania zapytań (Execution Plans) – jak je czytać i analizować

Po co czytać Execution Plans i jak je uruchamiać w SQL Server

Execution Plan, czyli plan wykonania zapytania, pokazuje w jaki sposób silnik SQL Server zamierza pobrać i przetworzyć dane, aby zwrócić wynik. To jedno z najważniejszych narzędzi do diagnozowania wydajności, bo pozwala zobaczyć nie tylko że zapytanie działa wolno, ale też dlaczego tak się dzieje. Dzięki temu można szybciej ustalić, czy problem wynika z nieoptymalnego dostępu do danych, nieodpowiednich indeksów, kosztownych operacji pośrednich albo błędnych założeń optymalizatora.

Czytanie planów wykonania jest przydatne zarówno podczas strojenia pojedynczego zapytania, jak i przy analizie problemów w całej bazie. W praktyce pomaga odpowiedzieć na kilka podstawowych pytań:

• czy SQL Server korzysta z indeksów, czy raczej przeszukuje duże zbiory danych,
• które fragmenty zapytania są najdroższe,
• czy optymalizator dobrze oszacował liczbę wierszy,
• czy wykonanie zapytania jest stabilne, czy zależy od parametrów i kontekstu uruchomienia,
• czy problem dotyczy konkretnego zapytania, czy wzorca widocznego także w historii obciążenia.

Warto podkreślić, że Execution Plan nie jest wyłącznie narzędziem dla administratorów baz danych. Korzystają z niego również programiści, analitycy danych i osoby odpowiedzialne za utrzymanie aplikacji, bo pozwala powiązać składnię zapytania z faktycznym zachowaniem silnika. To szczególnie ważne wtedy, gdy dwa pozornie podobne zapytania mają zupełnie inny czas wykonania.

W SQL Server istnieje kilka podstawowych sposobów uruchamiania i oglądania planów wykonania. Najbardziej bezpośrednim narzędziem jest SQL Server Management Studio. W SSMS można wyświetlić plan przewidywany jeszcze przed uruchomieniem zapytania albo plan rzeczywisty po jego wykonaniu. To najwygodniejsza forma pracy interaktywnej, ponieważ plan jest prezentowany graficznie i można od razu przejść do właściwości poszczególnych operatorów.

Drugą grupą narzędzi są ustawienia sesji takie jak SET STATISTICS. W praktyce wykorzystuje się je wtedy, gdy oprócz samego planu potrzebne są dodatkowe informacje diagnostyczne, na przykład o czasie wykonania lub o operacjach wejścia/wyjścia. To podejście jest szczególnie użyteczne przy porównywaniu kilku wersji tego samego zapytania, ponieważ daje bardziej tekstowy i pomiarowy obraz działania niż sam widok graficzny.

Trzecim ważnym źródłem jest Query Store. W odróżnieniu od analizy wykonywanej ręcznie w SSMS, Query Store przechowuje historię zapytań, planów i statystyk wykonania w samej bazie danych. Dzięki temu można sprawdzić, jaki plan był używany wcześniej, czy plan zmienił się po wdrożeniu nowej wersji aplikacji oraz czy pogorszenie wydajności wynika ze zmiany sposobu wykonania. To bardzo przydatne narzędzie wtedy, gdy problem nie występuje stale albo trudno go odtworzyć ręcznie.

Najprościej można więc spojrzeć na te trzy sposoby tak:

• SSMS służy głównie do bieżącej, ręcznej analizy konkretnego zapytania,
• SET STATISTICS pomaga zebrać dodatkowe metryki potrzebne do porównań i diagnostyki,
• Query Store pozwala analizować plany i wydajność w czasie, także po fakcie.

Umiejętność uruchamiania planów wykonania jest ważna nie tylko po to, by znaleźć błędy. To również sposób na świadome projektowanie zapytań. Dobrze napisane zapytanie nie zawsze będzie miało oczywiście poprawny plan, ale regularne sprawdzanie planów szybko uczy, jakie konstrukcje SQL są dla optymalizatora czytelne i wydajne, a jakie częściej prowadzą do problemów.

Na początku najlepiej traktować Execution Plan jako mapę decyzji podejmowanych przez silnik. Nie trzeba od razu znać wszystkich operatorów i ich właściwości. Najważniejsze jest zrozumienie, że plan pokazuje rzeczywistą strategię wykonania zapytania i stanowi punkt wyjścia do dalszej analizy wydajności.

Estimated vs Actual Execution Plan: różnice, kiedy używać którego i typowe pułapki interpretacji

W SQL Server można pracować z dwoma podstawowymi rodzajami planów wykonania: Estimated Execution Plan oraz Actual Execution Plan. Choć na pierwszy rzut oka często wyglądają podobnie, służą do nieco innych celów i pokazują inny poziom informacji. Podczas szkoleń Cognity ten temat wraca regularnie, dlatego zdecydowaliśmy się omówić go również tutaj.

Estimated Execution Plan to plan przewidywany przez optymalizator jeszcze przed uruchomieniem zapytania. Pokazuje, jak silnik zamierza wykonać operację na podstawie dostępnych statystyk, indeksów i reguł optymalizacji. Jest przydatny wtedy, gdy chcesz szybko sprawdzić potencjalny sposób wykonania zapytania bez jego uruchamiania, co bywa ważne przy ciężkich operacjach na dużych tabelach lub gdy samo wykonanie mogłoby trwać długo.

Actual Execution Plan powstaje podczas rzeczywistego uruchomienia zapytania. Oprócz samej struktury planu daje dostęp do informacji o tym, co faktycznie wydarzyło się w trakcie wykonania. Dzięki temu lepiej nadaje się do diagnostyki wydajności, ponieważ pozwala zestawić założenia optymalizatora z realnym przebiegiem operacji.

Najprościej można to ująć tak:

• Estimated Plan odpowiada na pytanie: „jak SQL Server planuje wykonać zapytanie?”
• Actual Plan odpowiada na pytanie: „jak SQL Server naprawdę wykonał zapytanie?”

W praktyce Estimated Plan warto wykorzystywać do szybkiej analizy, wstępnego przeglądu zapytania i oceny, czy optymalizator w ogóle wybiera sensowną strategię. To dobry wybór, gdy nie chcesz obciążać serwera pełnym wykonaniem albo analizujesz zapytanie jeszcze przed wdrożeniem zmian.

Actual Plan jest lepszy wtedy, gdy diagnozujesz realny problem wydajnościowy. Jeśli zapytanie działa wolno, zużywa zbyt dużo zasobów albo zachowuje się inaczej niż oczekiwano, plan rzeczywisty daje znacznie więcej wartości, bo pokazuje efekt końcowy, a nie tylko zamiar optymalizatora.

Trzeba jednak uważać na kilka częstych pułapek interpretacyjnych.

• Estimated Plan nie pokazuje pełnej prawdy o wykonaniu. To, że plan wygląda dobrze, nie oznacza jeszcze, że zapytanie zadziała dobrze w praktyce. Plan opiera się na estymacjach, a nie na rzeczywistych danych z wykonania.
• Actual Plan nie zawsze oznacza pełny obraz problemu. Jeśli analizujesz pojedyncze uruchomienie, możesz zobaczyć tylko jeden wariant zachowania zapytania. Czasem problem występuje tylko dla części parametrów, danych lub konkretnego obciążenia.
• Podobny wygląd planów może być mylący. Dwa plany mogą wyglądać niemal identycznie, ale różnić się istotnie w szczegółach wykonania. To właśnie te różnice często decydują o wydajności.
• Sam koszt widoczny na planie nie wystarcza do oceny. Udziały procentowe i wizualne podpowiedzi są pomocne, ale nie powinny być jedyną podstawą wniosków.
• Brak problemu w Estimated Plan nie wyklucza problemu w Actual Plan. Szczególnie wtedy, gdy optymalizator błędnie oszacował ilość danych lub warunki wykonania zmieniły się między kompilacją a uruchomieniem.

Najbezpieczniejsze podejście jest proste: Estimated Plan traktuj jako narzędzie do szybkiego rozpoznania, a Actual Plan jako podstawę do analizy rzeczywistego zachowania zapytania. Oba typy planów są przydatne, ale każdy odpowiada na trochę inne pytania i dopiero ich właściwe rozróżnienie pozwala uniknąć błędnych wniosków.

Jak czytać plan krok po kroku: kierunek przepływu danych, grubość strzałek, właściwości operatorów, ostrzeżenia

Samo otwarcie Execution Planu to dopiero początek. Najważniejsza umiejętność polega na tym, aby czytać plan w odpowiedniej kolejności i wiedzieć, na które elementy zwrócić uwagę najpierw. Dzięki temu można szybko ustalić, gdzie zapytanie zużywa najwięcej zasobów, które operacje przenoszą najwięcej danych i czy optimizer sygnalizuje potencjalny problem.

Na poziomie praktycznym analizę planu warto prowadzić w czterech krokach:

• ustalić kierunek przepływu danych,
• sprawdzić grubość strzałek między operatorami,
• odczytać właściwości najważniejszych operatorów,
• wyszukać ostrzeżenia i nietypowe oznaczenia.

Krok 1: zrozum kierunek czytania planu

Graficzny plan wykonania w SQL Server najczęściej czyta się od prawej do lewej, a przepływ danych kończy się po lewej stronie przy operatorze zwracającym wynik, zwykle SELECT. To oznacza, że operatory po prawej stronie są wykonywane wcześniej i dostarczają dane do kolejnych kroków.

W praktyce warto pamiętać o dwóch rzeczach:

• plan nie jest zwykłym diagramem kolejnych instrukcji — pokazuje zależności między operatorami,
• nie każdy element musi działać liniowo — niektóre fragmenty planu mogą być przetwarzane równolegle lub jako osobne gałęzie.

Najprostsza metoda czytania wygląda tak: zacznij od najbardziej prawego operatora w danej gałęzi, następnie przesuwaj się w lewo, obserwując, jak dane przechodzą przez kolejne kroki aż do wyniku końcowego.

Krok 2: patrz na strzałki, nie tylko na ikony

Bardzo częsty błąd początkujących polega na skupianiu się wyłącznie na nazwach operatorów. Tymczasem strzałki między operatorami niosą bardzo ważną informację: pokazują przepływ wierszy danych. Ich grubość jest wizualną podpowiedzią, ile danych przechodzi między poszczególnymi etapami planu.

Ogólna zasada jest prosta:

• grubsza strzałka — więcej wierszy przepływa przez ten fragment planu,
• cieńsza strzałka — mniej danych,
• nagłe poszerzenie strzałki — możliwy wzrost liczby przetwarzanych wierszy,
• nagłe zwężenie strzałki — silna filtracja lub agregacja danych.

To nie jest metryka absolutna, ale bardzo użyteczna wskazówka wizualna. Jeśli w planie od razu widać jedną wyjątkowo grubą strzałkę, zwykle warto zacząć analizę właśnie od tego miejsca, bo tam może pojawiać się największy przepływ danych.

Krok 3: otwieraj właściwości operatorów

Ikona operatora i jego nazwa to tylko skrót. Najwięcej informacji znajduje się w właściwościach operatora, dostępnych po kliknięciu elementu w planie. To właśnie tam można sprawdzić, co SQL Server zakładał, co rzeczywiście zrobił i jakiego typu danych dotyczyła dana operacja.

Podczas podstawowej analizy warto zwrócić uwagę przede wszystkim na:

• Estimated Number of Rows — przewidywana liczba wierszy,
• Actual Number of Rows — rzeczywista liczba wierszy, jeśli plan zawiera dane wykonania,
• Predicate lub Seek Predicate — warunek użyty przez operator,
• Output List — jakie kolumny operator przekazuje dalej,
• Estimated Operator Cost — szacowany koszt operatora w obrębie planu,
• Physical Operation i Logical Operation — fizyczny i logiczny charakter operacji.

Na tym etapie nie trzeba jeszcze interpretować każdej właściwości bardzo głęboko. Wystarczy rozumieć, że właściwości odpowiadają na cztery podstawowe pytania:

• ile danych przechodziło przez operator,
• jakie warunki były stosowane,
• co operator zwracał dalej,
• czy to, co przewidział optimizer, było zbliżone do rzeczywistości.

To właśnie te informacje pozwalają odróżnić operator, który tylko wygląda groźnie, od takiego, który faktycznie powoduje problem.

Krok 4: sprawdzaj procentowe koszty ostrożnie

W planie graficznym często widać procentowe wartości kosztu przy operatorach. To przydatna wskazówka, ale trzeba traktować ją z umiarem. Procent kosztu nie oznacza czasu wykonania ani rzeczywistego zużycia CPU czy I/O. Jest to przede wszystkim wewnętrzna estymacja optimizera dla porównania operatorów w ramach jednego planu.

Dlatego rozsądne podejście jest takie:

• używaj kosztów procentowych do wstępnego namierzenia podejrzanych miejsc,
• nie zakładaj automatycznie, że operator z najwyższym procentem jest jedynym problemem,
• zawsze zestawiaj koszt z liczbą wierszy, strzałkami i właściwościami operatora.

Jeżeli operator ma wysoki koszt procentowy, ale przetwarza niewiele danych i nie ma ostrzeżeń, może być mniej istotny niż operator o niższym koszcie, przez który przechodzą ogromne wolumeny wierszy.

Krok 5: wyszukuj ostrzeżenia

Execution Plan potrafi oznaczać miejsca wymagające uwagi specjalnymi ikonami ostrzegawczymi. Najczęściej są to żółte trójkąty widoczne na operatorze lub przy fragmencie planu. Taki sygnał nie zawsze oznacza krytyczny błąd, ale niemal zawsze warto go sprawdzić.

Do podstawowych ostrzeżeń, które warto zauważyć już na etapie pierwszego czytania planu, należą:

• implicit conversion — niejawna konwersja typów danych,
• spill — zapis części danych do tempdb,
• missing statistics lub problemy wpływające na estymację,
• warning przy operatorach równoległych lub pamięciowych.

Najlepiej traktować ostrzeżenia jako punkty do dalszej weryfikacji, a nie jako automatyczny wyrok. Czasem ostrzeżenie rzeczywiście wskazuje główną przyczynę problemu, a czasem jest tylko objawem czegoś, co dzieje się wcześniej w planie.

Na co patrzeć w pierwszej kolejności

Jeśli plan jest duży i złożony, dobrze jest mieć prostą listę priorytetów. W praktyce pierwsze czytanie planu można oprzeć na następującej kolejności:

1. znajdź najgrubsze strzałki,
2. sprawdź operatory z ostrzeżeniami,
3. kliknij elementy o najwyższym koszcie procentowym,
4. porównaj podstawowe właściwości operatorów, szczególnie liczbę wierszy,
5. oceń, czy przepływ danych wygląda logicznie względem tego, czego oczekujesz po zapytaniu.

Taka metoda pozwala szybko przejść od ogólnego obrazu do konkretnych punktów wymagających dokładniejszej analizy.

Najczęstsze błędy podczas czytania planu

• Czytanie planu od lewej do prawej — prowadzi do błędnej interpretacji kolejności operacji.
• Patrzenie tylko na nazwę operatora — bez sprawdzenia właściwości łatwo wyciągnąć fałszywe wnioski.
• Utożsamianie kosztu procentowego z rzeczywistym czasem — to tylko estymacja w obrębie planu.
• Ignorowanie strzałek — a to one często najłatwiej pokazują, gdzie przepływa najwięcej danych.
• Pomijanie ostrzeżeń — nawet jeśli nie są główną przyczyną problemu, zwykle dostarczają ważnych wskazówek.

Krótka ściąga

Dobrze czytany Execution Plan to nie zbiór przypadkowych ikonek, ale mapa przepływu danych. Najpierw warto zrozumieć skąd dane przychodzą, ile ich jest, przez które operatory przechodzą i czy plan sygnalizuje problemy. Taki sposób analizy daje solidną podstawę do dalszego diagnozowania wydajności zapytań.

4. Operatory dostępu do danych: Index Seek vs Index Scan, Table Scan, wpływ selektywności i indeksów

Jednym z pierwszych elementów, na które warto patrzeć w planie wykonania, są operatory odpowiedzialne za dostęp do danych. To one pokazują, w jaki sposób silnik SQL Server odczytuje wiersze z tabeli lub indeksu. W praktyce najczęściej spotkasz trzy podstawowe przypadki: Index Seek, Index Scan oraz Table Scan.

Sama nazwa operatora bywa myląca. Często przyjmuje się uproszczenie, że Seek jest zawsze dobry, a Scan zawsze zły. To nie jest prawda. Właściwy wybór zależy od ilości potrzebnych danych, dostępnych indeksów oraz tego, jak selektywny jest warunek filtrowania. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo w praktyce właśnie tutaj najłatwiej o zbyt daleko idące uproszczenia.

Index Seek

Index Seek oznacza, że SQL Server potrafi dotrzeć do konkretnego fragmentu danych przez strukturę indeksu, zamiast czytać go w całości. Najczęściej dzieje się tak wtedy, gdy zapytanie filtruje po kolumnie znajdującej się na początku klucza indeksu i warunek jest na tyle precyzyjny, że można zawęzić odczyt do niewielkiego zakresu.

• dobry przy wyszukiwaniu małej liczby wierszy,
• często pojawia się dla warunków typu =, >, >=, BETWEEN,
• jest szczególnie efektywny, gdy indeks dobrze odpowiada filtrowi zapytania.

Warto jednak pamiętać, że seek nie musi oznaczać odczytu jednego wiersza. Może to być również odczyt całego zakresu w indeksie. Dlatego nawet operator z nazwą Seek może przetwarzać dużo danych.

Index Scan

Index Scan oznacza odczyt większej części indeksu albo całego indeksu. SQL Server nadal korzysta z indeksu, ale nie może przejść od razu do wąskiego zestawu wierszy albo uznaje, że pełniejsze przejrzenie indeksu będzie bardziej opłacalne.

• pojawia się, gdy warunek jest mało selektywny,
• może być sensowny, gdy zapytanie zwraca dużą część tabeli,
• bywa lepszy niż Table Scan, jeśli indeks jest węższy od samej tabeli.

To ważne rozróżnienie: scan indeksu nie zawsze jest problemem. Jeśli indeks zawiera tylko potrzebne kolumny i jest znacznie mniejszy niż tabela bazowa, odczyt całego indeksu może być całkowicie uzasadniony.

Table Scan

Table Scan oznacza odczyt całej tabeli bez użycia indeksu, który pozwoliłby zawęzić dostęp. Taki operator występuje zwykle wtedy, gdy:

• na tabeli nie ma odpowiedniego indeksu,
• zapytanie potrzebuje bardzo dużej części danych,
• tabela jest mała i pełny odczyt jest po prostu najtańszy,
• warunek filtrowania uniemożliwia efektywne użycie indeksu.

W dużych tabelach Table Scan często jest sygnałem ostrzegawczym, ale w małych nie musi być niczym złym. Jeśli tabela ma kilkadziesiąt lub kilkaset wierszy, pełny odczyt może być szybszy niż przechodzenie przez dodatkowe struktury indeksów.

Porównanie operatorów

Wpływ selektywności

Selektywność opisuje, jak dobrze warunek filtrowania zawęża liczbę wierszy. Im mniej rekordów spełnia warunek, tym wyższa selektywność. To jeden z głównych powodów, dla których raz widzisz seek, a innym razem scan.

Przykładowo:

• warunek po unikalnym identyfikatorze zwykle ma wysoką selektywność,
• warunek po kolumnie, w której większość wierszy ma podobną wartość, zwykle ma niską selektywność.

Jeżeli zapytanie zwraca 1% danych, indeks często pomaga bardzo wyraźnie. Jeżeli jednak zwraca 70–90% tabeli, SQL Server może uznać, że skan będzie bardziej opłacalny niż wiele drobnych odczytów przez indeks.

Wpływ konstrukcji indeksu

Nie wystarczy, że indeks istnieje. Istotne jest również, jak jest zbudowany. Dla planu wykonania duże znaczenie mają:

• kolejność kolumn w kluczu indeksu — filtr po pierwszych kolumnach indeksu jest zwykle najłatwiejszy do wykorzystania,
• czy indeks pokrywa zapytanie — jeśli zawiera wszystkie potrzebne kolumny, odczyt może być tańszy,
• typ indeksu — najczęściej analizuje się indeksy rowstore: clustered i nonclustered,
• wielkość tabeli i indeksu — węższy indeks może być skanowany szybciej niż szeroka tabela.

Przykładowo, jeśli masz indeks na (KategoriaID, DataSprzedazy), to filtr zaczynający się od KategoriaID ma zwykle większą szansę na seek niż filtr wyłącznie po DataSprzedazy.

Kiedy brak seeka nie oznacza błędu

W planach wykonania łatwo wpaść w pułapkę prostego oceniania operatorów po nazwie. Tymczasem brak Index Seek nie musi oznaczać źle napisanego zapytania. Scan może być poprawnym wyborem, gdy:

• zapytanie zwraca dużą część danych,
• tabela jest niewielka,
• indeks jest węższy i tańszy do odczytu niż tabela,
• koszt użycia indeksu i dodatkowych odwołań do danych byłby większy niż pełny odczyt.

Najlepsza praktyka to patrzeć nie tylko na nazwę operatora, ale na jego kontekst: liczbę odczytywanych wierszy, rozmiar danych i dopasowanie indeksu do zapytania.

Krótki przykład

SELECT ProductID, Name
FROM Production.Product
WHERE ProductID = 100;

Dla takiego zapytania można oczekiwać Index Seek, jeśli istnieje indeks zaczynający się od ProductID.

SELECT ProductID, Name
FROM Production.Product
WHERE Color = 'Black';

Jeśli kolumna Color ma mało różnych wartości i wiele wierszy ma wartość Black, SQL Server może wybrać Index Scan albo nawet Table Scan, bo filtr nie zawęża danych wystarczająco mocno.

Na co patrzeć przy analizie tych operatorów

• czy operator czyta mały fragment danych, czy znaczną część obiektu,
• czy używany indeks odpowiada warunkom w WHERE,
• czy odczyt następuje z tabeli, czy z indeksu,
• czy pełny scan wynika z braku indeksu, czy z racjonalnej decyzji optymalizatora.

W praktyce operatory dostępu do danych bardzo często są pierwszą wskazówką, czy problem leży w braku odpowiedniego indeksu, niskiej selektywności filtra, czy po prostu w tym, że zapytanie potrzebuje dużej części danych i pełniejszy odczyt jest naturalny.

Operatory łączeń i dodatkowych operacji: Nested Loops, Hash Match, Sort oraz kiedy się pojawiają

W planie wykonania bardzo często najważniejsze pytanie brzmi nie tylko skąd SQL Server pobiera dane, ale też jak je ze sobą łączy i czy musi je dodatkowo przetwarzać przed zwróceniem wyniku. Właśnie tutaj pojawiają się operatory takie jak Nested Loops, Hash Match oraz Sort. To one w dużej mierze decydują o tym, czy zapytanie wykona się lekko i szybko, czy będzie wymagało większej ilości CPU, pamięci i czasu.

Nie ma operatora „zawsze najlepszego”. SQL Server dobiera je na podstawie przewidywanej liczby wierszy, dostępnych indeksów, rodzaju warunku łączenia oraz tego, czy dane muszą zostać posortowane lub zagregowane po drodze.

Nested Loops

Nested Loops to operator łączenia, który zwykle pojawia się wtedy, gdy jedna strona połączenia zwraca stosunkowo mało wierszy, a dla drugiej strony istnieje szybki sposób wyszukania pasujących danych, najczęściej przez indeks.

W uproszczeniu działa to tak:

• SQL Server bierze wiersz z pierwszego źródła,
• dla tego wiersza szuka dopasowania w drugim źródle,
• powtarza tę operację dla kolejnych wierszy.

To podejście bywa bardzo efektywne przy zapytaniach selektywnych, szczególnie gdy po stronie wewnętrznej można wykonać szybki seek. Jeśli jednak wierszy zewnętrznych jest dużo, operator może stać się kosztowny, bo wiele razy wykonuje podobne wyszukiwania.

Nested Loops często zobaczysz w sytuacjach takich jak:

• łączenie małego zbioru z większym,
• zapytania z dobrymi indeksami na kolumnach łączenia,
• operacje typu TOP lub bardzo selektywne filtry,
• scenariusze, w których optymalizator zakłada niewielką liczbę wynikowych wierszy.

Hash Match

Hash Match jest operatorem bardziej „siłowym”, ale bardzo użytecznym przy większych zbiorach danych. Najczęściej pojawia się wtedy, gdy SQL Server musi połączyć dużo wierszy, a dostęp przez indeks nie daje dużej przewagi albo odpowiednich indeksów po prostu brakuje.

W uproszczeniu jedna strona połączenia służy do zbudowania struktury haszującej w pamięci, a druga jest z nią porównywana w celu znalezienia dopasowań. Dzięki temu Hash Match dobrze radzi sobie przy dużych wolumenach danych i przy połączeniach typu równościowego, na przykład:

• t1.Id = t2.Id,
• duże zbiory wejściowe,
• słabsza selektywność filtrów,
• brak indeksów wspierających szybkie wyszukiwanie.

Hash Match nie służy wyłącznie do joinów. Może też występować przy:

• agregacjach,
• usuwaniu duplikatów,
• operacjach typu UNION, INTERSECT lub EXCEPT.

Ten operator bywa bardzo skuteczny, ale często potrzebuje więcej pamięci roboczej. Gdy danych jest dużo albo estymacje nie są trafne, może stać się jednym z cięższych elementów planu.

Sort

Sort nie jest operatorem łączenia, ale bardzo często pojawia się obok nich jako dodatkowa operacja przygotowująca dane. SQL Server używa go wtedy, gdy wynik lub kolejne operatory wymagają określonej kolejności wierszy.

Najbardziej typowe przypadki pojawienia się Sort to:

• ORDER BY,
• GROUP BY,
• DISTINCT,
• funkcje okna,
• przygotowanie danych do określonego typu łączenia lub agregacji.

Sort może być tani przy małych zbiorach, ale przy większych danych często staje się zauważalnym kosztem. Szczególnie wtedy, gdy nie da się wykorzystać kolejności wynikającej już z indeksu i trzeba wykonać pełne sortowanie od zera.

W praktyce obecność Sort nie oznacza automatycznie problemu. Jest to normalny operator, ale warto zwrócić uwagę, czy nie pojawia się tylko dlatego, że brakuje indeksu dostarczającego dane w odpowiedniej kolejności.

Kiedy najczęściej pojawiają się te operatory

Jak patrzeć na te operatory w planie

Podczas analizy planu warto zacząć od prostych pytań:

• Czy typ operatora pasuje do skali danych?
• Czy SQL Server łączy dane przez indeksy, czy musi wykonywać bardziej kosztowne operacje?
• Czy Sort wynika z logiki zapytania, czy z braku odpowiedniej struktury danych?
• Czy Hash Match pojawia się dlatego, że przetwarzany jest duży zbiór, czy dlatego, że optymalizator nie ma lepszej ścieżki?

Już taka podstawowa interpretacja pozwala szybko zorientować się, czy plan wygląda naturalnie, czy zawiera elementy, które mogą wymagać dalszej uwagi.

Krótki przykład

SELECT o.CustomerID, o.OrderID, c.CustomerID
FROM Sales.Orders o
JOIN Sales.Customers c
    ON o.CustomerID = c.CustomerID
ORDER BY o.CustomerID;

W takim zapytaniu można spodziewać się:

• Nested Loops lub Hash Match do połączenia tabel, zależnie od liczby wierszy i indeksów,
• Sort, jeśli dane nie są już dostępne w kolejności wymaganej przez ORDER BY.

Sama obecność tych operatorów nie jest niczym niezwykłym. Kluczowe jest to, czy zostały dobrane adekwatnie do charakteru zapytania i rozmiaru przetwarzanych danych.

6. Koszty i kardynalność: estimated rows vs actual rows, koszt operatorów, memory grant, błędy estymacji

Jednym z najważniejszych elementów analizy planu wykonania jest zrozumienie, ile wierszy optymalizator spodziewał się przetworzyć, a ile zostało przetworzonych w rzeczywistości. To właśnie kardynalność, czyli liczba wierszy przechodzących przez kolejne operatory, bardzo silnie wpływa na wybór całego planu: sposobu dostępu do danych, rodzaju połączeń, potrzeby sortowania czy wielkości przydzielonej pamięci.

W praktyce oznacza to, że nawet jeśli sam operator wygląda poprawnie, to błędna estymacja liczby wierszy może sprawić, że SQL Server wybierze plan, który będzie kosztowny dla realnych danych.

Estimated Rows vs Actual Rows

W planie wykonania często porównuje się dwie wartości:

• Estimated Rows – liczba wierszy przewidywana przez optymalizator podczas tworzenia planu,
• Actual Rows – liczba wierszy rzeczywiście przetworzona podczas wykonania zapytania.

Jeżeli te wartości są do siebie zbliżone, plan zwykle opiera się na trafnych założeniach. Jeżeli jednak różnica jest bardzo duża, może to oznaczać, że optymalizator podjął decyzję na podstawie nieaktualnych lub nieprecyzyjnych informacji.

Najbardziej niepokojące są sytuacje, w których różnica nie wynosi kilka czy kilkanaście procent, ale jest liczona w dziesiątkach, setkach albo tysiącach razy. Taki rozjazd często prowadzi do nieoptymalnych decyzji wykonawczych.

Koszt operatorów – co oznacza, a czego nie oznacza

W planie wykonania SQL Server prezentuje także koszty operatorów, zwykle jako procentowy udział w koszcie całego zapytania. Warto pamiętać, że nie jest to rzeczywisty czas wykonania ani realne zużycie CPU czy I/O, tylko wewnętrzny model kosztowy optymalizatora.

To ważne rozróżnienie, ponieważ operator pokazany jako „80% kosztu” nie musi być faktycznie głównym problemem wydajnościowym. Ten procent mówi raczej:

• jak optymalizator ocenił koszt danego kroku względem innych kroków,
• który fragment planu uznał za najdroższy przy swoich założeniach,
• gdzie warto zacząć analizę, ale nie gdzie na pewno jest źródło problemu.

Dlatego koszty operatorów najlepiej traktować jako wskazówkę pomocniczą, a nie ostateczny dowód. Jeśli estymacje liczby wierszy są błędne, to również wyliczone koszty mogą być mylące.

Dlaczego kardynalność ma tak duże znaczenie

Optymalizator buduje plan na podstawie przewidywanej liczby rekordów. Od tej wartości zależy między innymi:

• czy opłaca się sięgać po indeks,
• czy lepszy będzie operator dla małego czy dużego zbioru danych,
• czy trzeba przydzielić dużo pamięci roboczej,
• jakiej kolejności przetwarzania użyć.

Jeżeli SQL Server zakłada, że zapytanie zwróci kilka wierszy, a w praktyce zwraca setki tysięcy, może wybrać plan dobry dla małego zbioru, ale bardzo słaby dla dużego. Analogicznie, jeśli spodziewa się dużej liczby rekordów, a rzeczywiście danych jest mało, może zastosować zbyt ciężki wariant wykonania.

Memory Grant – przydział pamięci dla zapytania

Memory grant to ilość pamięci, którą SQL Server rezerwuje przed wykonaniem zapytania dla operatorów potrzebujących pamięci roboczej, na przykład do sortowania lub przetwarzania większych zestawów danych. Wielkość tego przydziału również wynika z estymacji.

Jeżeli estymacja liczby wierszy jest poprawna, pamięć zwykle zostaje przydzielona w rozsądnej ilości. Problemy pojawiają się w dwóch głównych przypadkach:

• za mały memory grant – zapytanie nie dostaje wystarczającej ilości pamięci i część operacji musi zostać wykonana z użyciem przestrzeni roboczej poza pamięcią,
• za duży memory grant – zapytanie rezerwuje znacznie więcej pamięci niż potrzebuje, co może ograniczać współbieżność i pogarszać pracę innych zapytań.

Z punktu widzenia diagnostyki warto więc patrzeć nie tylko na sam plan, ale też na to, czy przydział pamięci odpowiada rzeczywistej skali danych.

Typowe źródła błędów estymacji

Błędy estymacji nie oznaczają od razu błędu silnika. Najczęściej wynikają z ograniczeń informacji, którymi dysponuje optymalizator w chwili tworzenia planu. Do częstych przyczyn należą:

• nieaktualne statystyki – rozkład danych zmienił się, ale plan opiera się na starszym obrazie tabeli,
• nierównomierny rozkład danych – część wartości występuje bardzo często, a część bardzo rzadko,
• złożone predykaty – warunki filtrowania trudne do precyzyjnego oszacowania,
• korelacja kolumn – optymalizator może zakładać niezależność wartości, choć w danych istnieje zależność,
• parametry i zmienne – plan może być budowany dla innych założeń niż te, które występują przy danym wykonaniu,
• funkcje i przekształcenia w warunkach – utrudniają prawidłowe oszacowanie liczby dopasowań.

W efekcie problem z wydajnością nie zawsze wynika z „złego operatora” widocznego na ekranie, ale z tego, że operator otrzymał zupełnie inną liczbę wierszy niż przewidywano.

Na co patrzeć podczas analizy

Przy ocenie planu pod kątem kosztów i kardynalności warto zwrócić uwagę przede wszystkim na:

• duże rozbieżności między Estimated Rows i Actual Rows,
• operatory, dla których różnice występują wcześnie w planie, bo ich wpływ zwykle propaguje się dalej,
• nietypowo wysoki lub niski memory grant,
• koszty operatorów, ale zawsze w połączeniu z realnymi danymi wykonania,
• ostrzeżenia widoczne we właściwościach planu.

Dobra praktyka polega na tym, by nie patrzeć na pojedynczy wskaźnik w oderwaniu od reszty. Koszt, liczba wierszy i pamięć są ze sobą powiązane. Jeśli jedna z tych wartości jest błędnie oszacowana, pozostałe decyzje planu również mogą okazać się nietrafione.

Krótki przykład interpretacji

Jeżeli operator ma:

• Estimated Rows = 10,
• Actual Rows = 500000,

to można podejrzewać, że plan został zbudowany dla bardzo małego zbioru danych, mimo że rzeczywiste wykonanie przetwarza ogromną liczbę rekordów. Taka sytuacja często prowadzi do:

• niedoszacowania kosztu dalszych operacji,
• zbyt małego przydziału pamięci,
• wyboru planu nieadekwatnego do faktycznej skali danych.

Z kolei odwrotna sytuacja, gdy estymacja jest bardzo wysoka, a realnych wierszy jest niewiele, może powodować niepotrzebnie „ciężki” plan i nadmierne rezerwowanie zasobów.

Podsumowanie praktyczne

Analizując plan wykonania, warto pamiętać o kilku prostych zasadach:

• Estimated Rows pokazuje, co SQL Server przewidywał,
• Actual Rows pokazuje, co naprawdę się wydarzyło,
• koszt operatora to modelowa ocena optymalizatora, a nie rzeczywisty czas,
• memory grant jest skutkiem estymacji i może być zarówno zbyt mały, jak i zbyt duży,
• błędy estymacji są jedną z najczęstszych przyczyn słabych planów wykonania.

W wielu przypadkach to właśnie rozjazd między estymacją a rzeczywistością jest pierwszym sygnałem, że plan należy analizować głębiej.

Wnioskowanie z planu: jak diagnozować typowe problemy i dobierać działania naprawcze

Samo otwarcie planu wykonania nie rozwiązuje problemu wydajności. Największa wartość pojawia się wtedy, gdy z układu operatorów, ostrzeżeń i proporcji kosztów potrafisz wyciągnąć praktyczne wnioski: co dokładnie spowalnia zapytanie, dlaczego optymalizator wybrał taki sposób wykonania oraz jaką zmianę warto przetestować. Plan nie jest więc tylko obrazkiem, ale narzędziem diagnostycznym.

W codziennej analizie warto szukać przede wszystkim powtarzalnych wzorców. Nie każdy drogi operator oznacza błąd i nie każdy skan musi być problemem. Liczy się kontekst: rozmiar danych, liczba zwracanych wierszy, częstotliwość uruchomień oraz to, czy plan wskazuje na niepotrzebną pracę po stronie silnika.

Key Lookup: sygnał, że indeks nie pokrywa zapytania

Key Lookup często pojawia się wtedy, gdy silnik znajduje pasujące wiersze przy pomocy indeksu nieklastrowanego, ale potem musi wracać do danych bazowych po dodatkowe kolumny potrzebne w wyniku lub filtrze. Pojedynczy lookup nie jest zwykle problemem, ale przy dużej liczbie wierszy może stać się bardzo kosztowny, bo oznacza wiele dodatkowych odczytów.

Na planie warto zwrócić uwagę, czy operator ten wykonuje się wielokrotnie i czy jest powiązany z operatorem wyszukującym dużą liczbę rekordów. To typowy sygnał, że zapytanie korzysta z indeksu tylko częściowo.

Najczęstsze działania naprawcze to:

• rozważenie indeksu bardziej dopasowanego do zapytania, tak aby obejmował również potrzebne kolumny,
• ograniczenie liczby zwracanych kolumn, jeśli pobierane są dane, które nie są rzeczywiście potrzebne,
• sprawdzenie, czy filtr i kolejność kolumn w indeksie odpowiadają sposobowi użycia danych w zapytaniu.

Nie należy jednak automatycznie usuwać każdego Key Lookup. Jeżeli zapytanie zwraca niewiele wierszy, taki operator może być całkowicie akceptowalny.

Brakujące i nieużyteczne indeksy: wskazówka, nie wyrok

Plan może sugerować brakujące indeksy, ale takie podpowiedzi trzeba traktować ostrożnie. To raczej lokalna sugestia dla konkretnego zapytania niż pełna strategia indeksowania. Silnik nie bierze pod uwagę wszystkich kosztów utrzymania indeksu, wpływu na modyfikacje danych ani potencjalnego dublowania istniejących struktur.

Jeżeli plan wskazuje brakujący indeks, warto sprawdzić:

• czy podobny indeks już istnieje, ale nie jest optymalnie zdefiniowany,
• czy sugerowany indeks nie będzie niemal kopią innego indeksu,
• czy problem rzeczywiście dotyczy odczytu dużej liczby danych, a nie na przykład błędnej estymacji lub słabego filtra.

Z drugiej strony plan pomaga też rozpoznać indeksy nieużyteczne. Jeżeli zapytanie regularnie kończy się skanami mimo obecności wielu indeksów, może to oznaczać, że są one źle dobrane do wzorców filtrowania, mają nieodpowiednią kolejność kolumn albo nie wspierają najczęstszych zapytań. W praktyce mniej indeksów, ale lepiej dopasowanych, często daje lepszy efekt niż duża liczba przypadkowych struktur.

Skany: nie zawsze błąd, ale zawsze warto zrozumieć ich przyczynę

Table Scan lub Index Scan często budzą niepokój, ale sam skan nie jest jeszcze dowodem na złą wydajność. Dla małej tabeli albo zapytania zwracającego znaczną część danych skan może być najlepszym wyborem. Problem zaczyna się wtedy, gdy plan pokazuje skan dużego obiektu, a zapytanie teoretycznie powinno filtrować dane bardzo selektywnie.

Typowe przyczyny niepożądanych skanów to:

• brak odpowiedniego indeksu,
• użycie warunków utrudniających efektywne wyszukiwanie,
• niedopasowanie typów danych,
• funkcje lub przekształcenia wykonywane na kolumnach użytych w filtrze,
• błędne oszacowanie liczby wierszy przez optymalizator.

Działanie naprawcze powinno wynikać z przyczyny, a nie z samego faktu wystąpienia skanu. Czasem pomoże indeks, czasem uproszczenie warunku, a czasem aktualizacja statystyk lub zmiana konstrukcji zapytania.

Sort: dodatkowa praca i potencjalne wąskie gardło

Operator Sort oznacza, że silnik musi samodzielnie uporządkować dane, ponieważ nie otrzymał ich już w wymaganej kolejności. Sortowanie bywa kosztowne zwłaszcza przy dużych zbiorach, ponieważ zużywa pamięć i może opóźniać zwracanie wyników.

W planie warto sprawdzić, czy sort wynika z jawnego porządkowania wyników, czy jest potrzebny pośrednio do realizacji innych operacji. Jeżeli pojawia się regularnie i dotyczy dużej liczby wierszy, warto rozważyć:

• czy porządkowanie jest rzeczywiście potrzebne,
• czy istnieje indeks, który może dostarczyć dane w oczekiwanej kolejności,
• czy zapytanie nie przetwarza zbyt wielu rekordów przed etapem sortowania.

Nie każdy Sort należy eliminować za wszelką cenę, ale często jest on dobrym wskaźnikiem, że plan wykonuje kosztowną pracę, której można uniknąć lepszym dopasowaniem indeksów lub logiki zapytania.

Spill to tempdb: znak, że zabrakło pamięci roboczej

Jednym z ważniejszych ostrzeżeń w planie jest spill to tempdb. Oznacza on, że operator, najczęściej związany z sortowaniem lub przetwarzaniem większych zbiorów, nie zmieścił się w przydzielonej pamięci i musiał przenieść część pracy do tempdb. To zwykle pogarsza wydajność i zwiększa obciążenie dysku.

Taki objaw bywa skutkiem:

• zbyt małego przydziału pamięci,
• niedoszacowania liczby wierszy,
• przetwarzania większego zbioru niż potrzebny,
• operacji wymagających kosztownego sortowania lub haszowania.

W praktyce należy wtedy sprawdzić nie tylko sam operator z ostrzeżeniem, ale również wcześniejsze etapy planu. Często źródłem problemu nie jest sam Sort czy Hash Match, lecz to, że wcześniejszy filtr nie ograniczył danych tak skutecznie, jak zakładał optymalizator. Rozwiązaniem może być poprawa estymacji, lepszy indeks, zmiana kształtu zapytania albo ograniczenie danych wcześniej w planie.

Parametr sniffing: ten sam kod, różne zachowanie

Parametr sniffing to sytuacja, w której plan został skompilowany na podstawie konkretnej wartości parametru i później jest używany także dla innych wartości, choć ich rozkład danych może być zupełnie inny. W efekcie jedno wykonanie działa bardzo dobrze, a kolejne bardzo wolno, mimo że korzystają z tego samego zapytania.

W planie można to podejrzewać wtedy, gdy:

• rzeczywista liczba przetwarzanych wierszy mocno odbiega od przewidywań,
• to samo zapytanie raz wybiera plan „lekki”, a innym razem zachowuje się tak, jakby było zoptymalizowane pod inny przypadek,
• problem występuje nieregularnie i zależy od wartości wejściowych.

Działania naprawcze mogą obejmować zmianę sposobu kompilacji planu, przebudowę zapytania lub takie przygotowanie indeksów i statystyk, aby plan był bardziej stabilny dla różnych parametrów. Najważniejsze jest jednak poprawne rozpoznanie przyczyny: nie każdy zły plan dla zapytania parametryzowanego oznacza parametr sniffing.

Jak dobierać działania naprawcze z planu

Najczęstszy błąd polega na reagowaniu na pojedynczy operator bez spojrzenia na cały przebieg zapytania. Dobra analiza planu powinna odpowiadać na trzy pytania:

• który fragment wykonuje najwięcej niepotrzebnej pracy,
• czy problem wynika z dostępu do danych, błędnej estymacji czy kosztownej operacji pośredniej,
• czy proponowana poprawka pomoże temu zapytaniu bez pogorszenia innych obciążeń.

W praktyce działania naprawcze najczęściej mieszczą się w kilku grupach:

• zmiana lub dodanie indeksu,
• uproszczenie warunków i logiki zapytania,
• ograniczenie liczby odczytywanych i zwracanych danych,
• poprawa jakości statystyk i estymacji,
• rozwiązanie problemów związanych z planem zależnym od parametrów,
• eliminacja zbędnych sortów, lookupów i przetwarzania pośredniego.

Najlepsze efekty daje podejście iteracyjne: zidentyfikować dominujący problem, wprowadzić jedną zmianę, porównać plan i czas wykonania, a dopiero potem przechodzić dalej. Execution Plan nie służy do zgadywania, lecz do podejmowania decyzji opartych na tym, gdzie silnik naprawdę traci czas, pamięć i odczyty.

8. Mini-słowniczek operatorów i najczęstszych ikon/ostrzeżeń w planie

Na pierwszy rzut oka plan wykonania może wyglądać jak zbiór niezrozumiałych ikonek połączonych strzałkami. W praktyce wiele z nich powtarza się bardzo często, dlatego warto znać ich podstawowe znaczenie. Taki skrócony słowniczek pomaga szybciej wychwycić, czy zapytanie działa przewidywalnie, czy już na poziomie ogólnego obrazu widać potencjalny problem.

• Index Seek – operator wskazujący, że silnik odszukuje dane w indeksie w sposób ukierunkowany. Zwykle jest to dobry znak, bo oznacza bardziej precyzyjny dostęp do danych.
• Index Scan – odczyt większej części indeksu lub całego indeksu. Nie zawsze oznacza problem, ale często sugeruje, że trzeba było przeczytać więcej danych, niż intuicyjnie by się chciało.
• Table Scan – skan całej tabeli. Może być naturalny przy małych tabelach, ale przy większych obiektach bywa sygnałem kosztownego odczytu.
• Key Lookup – dodatkowe pobranie brakujących kolumn z tabeli lub indeksu klastrowego po wcześniejszym znalezieniu wierszy w indeksie nieklastrowym. Często pojawia się przy częściowo dopasowanych indeksach.
• RID Lookup – podobny do Key Lookup, ale występuje w tabelach bez indeksu klastrowego. Oznacza konieczność dodatkowego sięgania po pełne dane wiersza.
• Nested Loops – metoda łączenia danych, zwykle dobrze sprawdzająca się przy mniejszych zestawach lub gdy jeden z wejściowych zbiorów jest niewielki.
• Hash Match – operator używany często przy większych zbiorach danych, zwłaszcza przy łączeniach i agregacjach. Jest skuteczny, ale może wymagać więcej pamięci.
• Merge Join – łączenie danych uporządkowanych według wspólnego klucza. Często jest korzystne wtedy, gdy dane są już posortowane lub łatwo je uporządkować.
• Sort – operator odpowiedzialny za sortowanie danych. Może być potrzebny logicznie, ale jest też częstym źródłem dodatkowego kosztu i zapotrzebowania na pamięć.
• Filter – dodatkowe odfiltrowanie wierszy po wykonaniu wcześniejszych operacji. Pokazuje, że warunek nie zawsze został zastosowany od razu na etapie dostępu do danych.
• Compute Scalar – obliczanie wyrażeń, konwersji lub prostych wartości pośrednich. Sam w sobie zwykle nie jest groźny, ale warto sprawdzić, co dokładnie wylicza.
• Stream Aggregate – agregacja wykonywana na danych uporządkowanych. Często jest lekka i efektywna, jeśli wejście ma odpowiednią postać.
• Hash Aggregate – agregacja oparta na strukturze haszującej. Bywa wybierana przy większych lub nieuporządkowanych zbiorach danych.
• Concatenation – operator łączący kilka strumieni danych w jeden wynik. Często pojawia się przy zapytaniach z warunkami alternatywnymi lub konstrukcjach typu UNION ALL.
• Parallelism – oznacza, że zapytanie zostało rozdzielone na kilka wątków. Sam fakt użycia równoległości nie jest ani dobry, ani zły, ale pokazuje, że optymalizator uznał operację za na tyle kosztowną, by rozważyć wykonanie wielowątkowe.
• Table Spool lub Index Spool – tymczasowe przechowanie danych do ponownego użycia w trakcie wykonania planu. Czasem pomaga ograniczyć powtarzane odczyty, a czasem sygnalizuje mniej optymalny przebieg operacji.

Poza samymi operatorami bardzo ważne są też ikony ostrzeżeń i charakterystyczne oznaczenia widoczne w planie. To one często najszybciej podpowiadają, gdzie warto skierować uwagę.

• Żółty trójkąt ostrzeżenia – najbardziej charakterystyczny sygnał, że przy operatorze wystąpiło coś wartego uwagi. Może dotyczyć problemów z pamięcią, konwersji typów, przetwarzania równoległego albo operacji zapisujących dane tymczasowe poza pamięcią.
• Missing Index – sugestia, że według optymalizatora dodatkowy indeks mógłby pomóc temu konkretnemu zapytaniu. To tylko wskazówka, a nie automatyczna rekomendacja do wdrożenia bez analizy.
• Implicit Conversion – niejawna konwersja typu danych. Często bywa niepozorna, ale może utrudniać efektywne użycie indeksów i pogarszać wydajność.
• Spill to tempdb – informacja, że operatorowi zabrakło pamięci roboczej i część danych została przeniesiona do tempdb. To częsty sygnał, że wykonanie było cięższe, niż zakładano.
• Operator time-out lub early termination of optimization – ślad po tym, że optymalizator nie analizował wszystkich możliwych wariantów planu wystarczająco długo. Nie zawsze prowadzi to do złego planu, ale warto mieć to na uwadze.
• Różnice między przewidywaną a rzeczywistą liczbą wierszy – nie są osobną ikoną, ale należą do najważniejszych oznak problemu. Gdy liczby mocno się rozchodzą, plan może być logicznie poprawny, ale słabo dopasowany do realnych danych.
• Grube strzałki przepływu – wizualna podpowiedź, że przez dany fragment planu przechodzi dużo danych. To nie ostrzeżenie formalne, ale bardzo użyteczna wskazówka przy szybkim przeglądzie planu.
• Ikony równoległości – pokazują miejsca rozdzielania i scalania pracy między wątkami. Warto je zauważać, bo pomagają zrozumieć, czy koszt zapytania był na tyle duży, by uruchomić wykonanie równoległe.

Najlepsze pierwsze podejście do planu to nie próba zrozumienia wszystkiego naraz, lecz rozpoznanie kilku najczęściej spotykanych symboli: sposobu dostępu do danych, rodzaju łączenia, ewentualnego sortowania, lookupów oraz obecności ostrzeżeń. Już taka podstawowa orientacja pozwala odróżnić plan wyglądający zdrowo od planu, który wymaga dokładniejszej analizy.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

PowerApps: wzorce obsługi załączników i dużych plików — limity, skan AV i ścieżka do SharePoint/Blob 05 maja 2026

Power Automate: wzorzec „kompensacji” (undo) w procesach — jak cofać zmiany bez ręcznego sprzątania 03 maja 2026