SQL Server — optymalizacja wydajności i tuning zapytań

SQL server optymalizacja — jak skutecznie przyspieszyć bazę i zapytania w 2026 roku?

SQL Server optymalizacja zaczyna się nie od dodawania kolejnych indeksów, ale od ustalenia, które zapytania, plany wykonania, statystyki i oczekiwania naprawdę zużywają czas użytkowników. Jeśli aplikacja ERP, sklep B2B, system magazynowy albo raportowanie w Twojej firmie zwalnia po kilku miesiącach pracy, problem zwykle nie leży w jednym magicznym ustawieniu. Najczęściej widzisz mieszankę: brakujący indeks, przestarzałe statystyki, zły plan po parameter sniffing, przeciążone tempdb, blokady albo zapytanie pobierające 500 000 wierszy tam, gdzie ekran pokazuje 50. Ten przewodnik łączy sql server tuning, sql query optimization, sql server execution plan, sql server statistics i sql index strategy w praktyczny playbook dla małego lub średniego zespołu DBA i developerów.

W tym kompleksowym przewodniku otrzymasz praktyczny plan działania, który pozwoli Ci na samodzielne przeprowadzenie tuningu wydajności. Przedstawimy szczegółową tabelę porównawczą typów indeksów, macierz najczęstszych typów oczekiwań (wait stats) wraz z rekomendacjami naprawczymi, a także krok po kroku wyjaśnimy, jak czytać plany wykonania zapytań i identyfikować wąskie gardła. Znajdziesz tu również konkretne przykłady kodu T-SQL, które możesz zastosować w swojej bazie danych, aby natychmiast poprawić jej responsywność. Przygotuj się na solidną dawkę wiedzy, która odmieni sposób, w jaki podchodzisz do zarządzania wydajnością SQL Server.

Wydajna baza potrzebuje stabilnego silnika i przewidywalnej platformy serwerowej. Jeśli budujesz lub modernizujesz środowisko produkcyjne, sprawdź kategorię Microsoft SQL Server, licencje w kategorii klucz Windows Server oraz Windows Server 2022 Standard. Dobrze dobrana licencja nie zastępuje tuningu, ale ułatwia utrzymanie środowiska, w którym łatwiej zaplanować pamięć, dyski, kopie zapasowe, okna serwisowe i rozwój aplikacji.

Zrozumienie i diagnostyka wąskich gardeł w SQL Server

Zanim przystąpisz do optymalizacji, musisz zlokalizować, co dokładnie spowalnia Twoją bazę danych. Najczęściej problemy z wydajnością wynikają z niedostatecznego indeksowania, źle napisanych zapytań, nieaktualnych statystyk, niewystarczających zasobów sprzętowych lub blokad. Kluczem do sukcesu jest metodyczna diagnostyka.

Statystyki oczekiwania (Wait Statistics) — podstawa diagnostyki

Statystyki oczekiwania (wait statistics) to najcenniejsze źródło informacji o tym, na co dokładnie czeka SQL Server. Każde zapytanie, które nie wykonuje się natychmiast, czeka na jakiś zasób – może to być dostęp do dysku, pamięć RAM, CPU, blokada, czy sieć. Analiza tych statystyk pozwala zidentyfikować główne przyczyny opóźnień.

Widok dynamicznego zarządzania (DMV) sys.dm_os_wait_stats agreguje dane o wszystkich typach oczekiwań od momentu ostatniego uruchomienia serwera. Monitorowanie tego widoku w czasie pozwala na zidentyfikowanie trendów i dominujących typów oczekiwań, które wskazują na konkretne wąskie gardła.

• PAGEIOLATCH_*: Oczekiwanie na strony danych z dysku. Wysokie wartości wskazują na problem z wydajnością I/O (wolne dyski, brak pamięci buforowej).
• CXPACKET: Oczekiwanie na synchronizację równoległych wątków. Może wskazywać na problem z progiem równoległości (MAXDOP) lub nieefektywne plany równoległe.
• LCK_M_*: Oczekiwanie na zwolnienie blokady. Wskazuje na problemy z konkurencją do danych i blokowaniem.
• SOS_SCHEDULER_YIELD: Oczekiwanie na przydzielenie czasu CPU. Sugeruje duże obciążenie procesora lub niewystarczającą liczbę rdzeni.

Więcej o monitorowaniu wydajności za pomocą statystyk oczekiwania znajdziesz na Microsoft Learn.

Przykład zapytania, które pomoże Ci zidentyfikować top 10 typów oczekiwań od ostatniego restartu serwera:

SELECT
    wait_type,
    wait_time_ms / 1000.0 AS wait_time_s,
    CAST(100. * wait_time_ms / SUM(wait_time_ms) OVER() AS NUMERIC(10,2)) AS percentage_wait,
    (wait_time_ms - signal_wait_time_ms) / 1000.0 AS resource_wait_s,
    signal_wait_time_ms / 1000.0 AS signal_wait_s,
    waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE 'SLEEP%'
    AND wait_type NOT LIKE 'ONDEMAND_TASK_QUEUE'
    AND wait_type NOT LIKE 'FT_IFTS_SCHEDULER_IDLE_WAIT'
    AND wait_type NOT LIKE 'SQLTRACE_BUFFER_FLUSH'
    AND wait_type NOT LIKE 'REQUEST_FOR_DEADLOCK_SEARCH'
    AND wait_type NOT LIKE 'BROKER_TASK_STOP'
    AND wait_type NOT LIKE 'BROKER_TO_FLUSH'
    AND wait_time_ms > 0
ORDER BY wait_time_ms DESC;

Pamiętaj, że resetowanie statystyk oczekiwania może być przydatne do monitorowania zmian po wprowadzeniu optymalizacji. Możesz to zrobić za pomocą polecenia:

DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

Plany wykonania zapytań (Execution Plans) — jak czytać i rozumieć

Plan wykonania zapytania to graficzna lub tekstowa reprezentacja kroków, jakie SQL Server podejmuje, aby wykonać dane zapytanie T-SQL. To swoista mapa drogowa, która pokazuje, gdzie zapytanie spędza najwięcej czasu, jakie indeksy są używane (lub ignorowane) i gdzie występują kosztowne operacje, takie jak skanowanie tabel (Table Scan) zamiast wyszukiwania indeksu (Index Seek).

Wyróżniamy dwa główne typy planów wykonania:

• Szacowany plan wykonania (Estimated Execution Plan): Generowany przez optymalizator zapytań bez faktycznego uruchamiania zapytania. Jest użyteczny do szybkiej analizy potencjalnych problemów.
• Rzeczywisty plan wykonania (Actual Execution Plan): Generowany po wykonaniu zapytania, zawiera rzeczywiste dane o liczbie wierszy, czasie i zużytych zasobach. Jest o wiele dokładniejszy i powinien być używany do ostatecznej weryfikacji optymalizacji.

Aby wygenerować rzeczywisty plan wykonania w SQL Server Management Studio (SSMS), zaznacz zapytanie i kliknij "Include Actual Execution Plan" lub użyj polecenia T-SQL:

DECLARE @CustomerID int = 11000;

SET STATISTICS PROFILE ON;

SELECT
    soh.SalesOrderID,
    soh.OrderDate,
    soh.TotalDue
FROM Sales.SalesOrderHeader AS soh
WHERE soh.CustomerID = @CustomerID
  AND soh.Status = 5
ORDER BY soh.OrderDate DESC;

SET STATISTICS PROFILE OFF;

Kluczowe elementy do analizy w planie wykonania:

• Koszt operatorów: Każdy operator w planie ma przypisany procent kosztu. Skup się na operatorach z najwyższym kosztem.
• Skanowanie tabel (Table Scan): Zwykle jest to bardzo kosztowna operacja, zwłaszcza w dużych tabelach, wskazująca na brak odpowiedniego indeksu. Zamiast tego szukaj Index Seek.
• Sortowanie (Sort): Często wskazuje na brak indeksu pokrywającego klauzulę ORDER BY.
• Sprzężenia (Joins): Zwróć uwagę na typy sprzężeń (Nested Loops, Hash Match, Merge Join). Hash Match jest często kosztowny dla dużych zbiorów danych.
• Ostrzeżenia (Warnings): Żółty trójkąt z wykrzyknikiem wskazuje na potencjalne problemy, np. brakujące statystyki, konwersje typów danych (Implicit Conversion) lub przepełnienie tempdb.
• Różnice między Estimated a Actual Rows: Duże rozbieżności wskazują na nieaktualne statystyki lub problemy z parametrem sniffing.

Strategie indeksowania — fundament wydajności

Indeksy są najważniejszym narzędziem optymalizacyjnym w SQL Server. Dobrze zaprojektowana strategia indeksowania może znacząco poprawić wydajność odczytu danych, jednocześnie minimalizując negatywny wpływ na operacje zapisu. Pamiętaj, że indeksy wymagają przestrzeni dyskowej i spowalniają operacje INSERT, UPDATE i DELETE, dlatego ich projektowanie musi być zrównoważone.

Typy indeksów w SQL Server 2022

SQL Server 2022 wprowadza usprawnienia, które pozwalają na jeszcze lepsze dopasowanie indeksów do obciążeń, zwłaszcza w środowiskach OLTP i analitycznych.

Kluczem do tworzenia efektywnych indeksów jest analiza zapytań, które spowalniają system (za pomocą planów wykonania lub Query Store) i dobór odpowiedniego typu indeksu. Dla często odczytywanych kolumn, używanych w klauzulach WHERE, JOIN, ORDER BY lub GROUP BY, indeksy są niezbędne.

Przykład tworzenia indeksu nieklastrowanego z klauzulą INCLUDE, który pokryje zapytanie wybierające OrderDate i TotalDue dla konkretnego CustomerID:

CREATE NONCLUSTERED INDEX IX_SalesOrderHeader_CustomerID_OrderDate
ON Sales.SalesOrderHeader (CustomerID)
INCLUDE (OrderDate, TotalDue)
WHERE Status = 5
WITH (DROP_EXISTING = OFF, ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = SELF)));

Zwróć uwagę na klauzulę WAIT_AT_LOW_PRIORITY, dostępną od SQL Server 2014, która pozwala na wykonywanie operacji na indeksach online z niskim priorytetem. W SQL Server 2022 funkcjonalność ta jest jeszcze bardziej dopracowana, minimalizując wpływ na działające transakcje. Więcej informacji znajdziesz na Microsoft Learn o CREATE INDEX.

Zarządzanie statystykami — paliwo dla optymalizatora

Statystyki są metadanymi opisującymi rozkład danych w kolumnach tabeli. Optymalizator zapytań wykorzystuje te statystyki do oszacowania liczby wierszy, które zostaną zwrócone przez zapytanie, i na tej podstawie wybiera najbardziej efektywny plan wykonania. Nieaktualne statystyki to częsta przyczyna wolnych zapytań.

SQL Server automatycznie tworzy i aktualizuje statystyki, ale w dynamicznych środowiskach może być konieczne ręczne wymuszenie aktualizacji. Od SQL Server 2022 dostępna jest nowa funkcja AUTO_DROP dla statystyk, która pozwala na automatyczne usuwanie statystyk utworzonych przez użytkownika, jeśli blokują one operacje zmiany schematu.

Aby zaktualizować statystyki dla konkretnej tabeli lub kolumny:

UPDATE STATISTICS Production.Product (AK_Product_ProductNumber);

Dla całej bazy danych:

EXEC sp_updatestats;

Więcej o statystykach w SQL Server znajdziesz na Microsoft Learn.

Tuning zapytań i zaawansowane techniki optymalizacji

Poza indeksowaniem i statystykami istnieje wiele technik na poziomie samego zapytania T-SQL, które mogą znacząco poprawić wydajność.

Identyfikacja najdroższych zapytań (Top Expensive Queries)

Zamiast optymalizować wszystkie zapytania, skup się na tych, które zużywają najwięcej zasobów (CPU, I/O, czas wykonania). Widok sys.dm_exec_query_stats dostarcza zagregowanych informacji o wykonanych zapytaniach.

SELECT TOP 10
    total_worker_time / execution_count AS avg_cpu_time,
    total_elapsed_time / execution_count AS avg_elapsed_time,
    total_logical_reads / execution_count AS avg_logical_reads,
    SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
              ((CASE qs.statement_end_offset
                  WHEN -1 THEN DATALENGTH(st.text)
                  ELSE qs.statement_end_offset
               END - qs.statement_start_offset) / 2) + 1) AS statement_text,
    qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
ORDER BY avg_cpu_time DESC;

To zapytanie zwróci 10 najdroższych zapytań pod względem średniego czasu CPU, wraz z ich tekstem i planem wykonania, co jest doskonałym punktem wyjścia do dalszej analizy.

Parameter Sniffing — pułapka optymalizatora

Parameter sniffing występuje, gdy optymalizator zapytań tworzy plan wykonania dla sparametryzowanego zapytania, opierając się na wartościach parametrów użytych podczas pierwszego wykonania tego zapytania. Jeśli te początkowe wartości nie są reprezentatywne dla typowych danych, plan może być nieoptymalny dla kolejnych wykonań z innymi wartościami parametrów.

Rozwiązania problemu parameter sniffing:

• OPTION (RECOMPILE): Wymusza ponowne skompilowanie planu wykonania przy każdym uruchomieniu zapytania. Jest to dobre dla zapytań, które mają bardzo zmienne parametry i nie są często wykonywane.
• OPTIMIZE FOR UNKNOWN: Nakazuje optymalizatorowi ignorowanie wartości parametru i generowanie planu na podstawie ogólnych statystyk.
• Zmienne lokalne: Przypisanie wartości parametru do zmiennej lokalnej w procedurze składowanej może zmusić optymalizator do stworzenia planu bazującego na gęstości danych, a nie konkretnej wartości.

Przykład użycia OPTION (RECOMPILE):

DECLARE @ProductNumber nvarchar(25) = N'BK-';

SELECT ProductID, Name, ProductNumber
FROM Production.Product
WHERE ProductNumber LIKE @ProductNumber + '%'
OPTION (RECOMPILE);

Zarządzanie zasobami i konfiguracja serwera

Optymalizacja SQL Server to nie tylko indeksy i zapytania, ale także odpowiednia konfiguracja serwera i systemu operacyjnego. Upewnij się, że SQL Server ma wystarczającą ilość pamięci RAM i dostęp do szybkich dysków. Ważne jest również odpowiednie ustawienie MAXDOP (Maximum Degree of Parallelism) i Cost Threshold for Parallelism, aby kontrolować użycie zasobów CPU.

Monitoruj liczniki wydajności (Performance Counters) Windows i SQL Server, takie jak:

• Processor\% Processor Time: Obciążenie CPU.
• Memory\Available MBytes: Dostępna pamięć fizyczna.
• PhysicalDisk\Avg. Disk sec/Read, Avg. Disk sec/Write: Czas odpowiedzi dysku.
• SQL Server:Buffer Manager\Page life expectancy: Czas, przez jaki strony danych pozostają w pamięci RAM. Niskie wartości wskazują na presję na pamięć.

Praktyczny playbook: od objawu do poprawki

Największy błąd w tuningu SQL Server polega na tym, że zaczynasz od rozwiązania, a nie od dowodu. Developer widzi sugestię missing index w planie i od razu tworzy indeks. Administrator widzi wysokie PAGEIOLATCH_SH i od razu planuje zakup dysków. Właściciel aplikacji widzi powolny raport i prosi o większy serwer. Każda z tych reakcji może być poprawna, ale tylko po potwierdzeniu danych. Microsoft opisuje ogólne podejście do monitorowania i strojenia wydajności w dokumentacji Monitorowanie i dostrajanie wydajności; w praktyce SMB warto przełożyć je na prostą sekwencję roboczą.

Pierwszy krok to ustalenie zakresu: czy wolna jest cała instancja, jedna baza, jedna procedura, jeden ekran aplikacji czy tylko raport wykonywany o 8:00 rano. Drugi krok to zebranie danych z tego samego przedziału czasu, w którym użytkownik widzi problem. Średnie statystyki od restartu serwera są pomocne, ale mogą ukryć krótki, intensywny problem. Trzeci krok to sprawdzenie planu wykonania i realnych liczników: odczytów logicznych, czasu CPU, czasu całkowitego, liczby wykonań i rozbieżności między wierszami szacowanymi a rzeczywistymi. Dopiero czwarty krok to zmiana: indeks, poprawka zapytania, aktualizacja statystyk, wymuszenie planu, zmiana ustawienia albo korekta aplikacji.

Dla małego zespołu dobry rytm pracy wygląda tak: rano sprawdzasz Query Store i najdroższe zapytania z ostatnich 24 godzin, raz w tygodniu analizujesz indeksy z dużą liczbą odczytów i kosztowną konserwacją, po każdej większej migracji danych aktualizujesz statystyki, a po każdym wdrożeniu aplikacji porównujesz regresje planów. Nie potrzebujesz rozbudowanej platformy APM, aby zacząć. SQL Server ma wystarczająco dużo wbudowanych widoków DMV, planów XML, Query Store i liczników, aby znaleźć najczęstsze problemy bez instalowania dodatkowych agentów.

Query Store jako dziennik regresji wydajności

Query Store przechowuje historię zapytań, planów i statystyk wykonania, dlatego jest jednym z najważniejszych narzędzi w SQL Server 2022. Dokumentacja Monitorowanie wydajności przy użyciu magazynu zapytań pokazuje, że Query Store pozwala porównać różne plany tego samego zapytania oraz wykryć regresję po zmianie statystyk, indeksów albo wersji aplikacji. W SQL Server 2022 Query Store jest domyślnie włączany dla nowych baz danych, ale w starszych bazach po migracji warto to sprawdzić jawnie.

W produkcji nie ustawiaj Query Store bez limitów. Daj mu rozsądny budżet miejsca i tryb automatycznego czyszczenia, bo baza z tysiącami unikalnych zapytań ad hoc może szybko zebrać dużo planów. Dla typowej aplikacji biznesowej dobrym punktem startowym jest zbieranie danych w trybie automatycznym, sensowny limit rozmiaru oraz osobna procedura przeglądu zapytań z regresją. Query Store nie zastępuje czytania planu wykonania, ale daje odpowiedź na pytanie, które zwykle jest najtrudniejsze: co zmieniło się od momentu, gdy było dobrze.

SELECT
    actual_state_desc,
    desired_state_desc,
    current_storage_size_mb,
    max_storage_size_mb,
    query_capture_mode_desc,
    wait_stats_capture_mode_desc,
    readonly_reason
FROM sys.database_query_store_options;

Jeżeli actual_state_desc wskazuje READ_ONLY, Query Store przestał zapisywać nowe dane. Przyczyną może być osiągnięty limit miejsca, tryb awaryjny albo ustawienie administracyjne. Wtedy najpierw przywróć zbieranie danych, a dopiero później analizuj regresję. Gdy Query Store działa, sprawdzaj zapytania o największym wzroście czasu wykonania, a nie tylko największe zapytania globalnie. Zapytanie, które zawsze trwało 30 sekund, jest problemem stałym. Zapytanie, które wczoraj trwało 80 ms, a dziś trwa 8 sekund, jest regresją i zwykle ma konkretną przyczynę.

Jak czytać rzeczywisty plan wykonania bez zgadywania

Rzeczywisty plan wykonania nie jest obrazkiem do szybkiego kliknięcia. To dokument techniczny, który pokazuje, jakie operatory zostały wykonane, ile wierszy optymalizator przewidywał, ile wierszy faktycznie przepłynęło przez operator i gdzie pojawiły się ostrzeżenia. Dokumentacja Wyświetlanie rzeczywistego planu wykonania opisuje włączenie planu w SSMS, ale w pracy produkcyjnej przydaje się też zapis planu XML do analizy poza oknem aplikacji.

Czytaj plan od prawej do lewej, ale nie daj się prowadzić wyłącznie procentom kosztu. Procent kosztu jest szacunkiem optymalizatora, a nie pomiarem stopera. Najpierw szukaj ostrzeżeń: Missing Index, Spill to tempdb, Implicit Conversion, Excessive Grant, Columns With No Statistics. Potem porównaj Estimated Number of Rows z Actual Number of Rows. Różnica rzędu 10 razy jest sygnałem ostrzegawczym; różnica rzędu 1000 razy zwykle tłumaczy zły dobór joinów, sortowań i pamięci. Następnie sprawdź, czy plan robi Index Seek z wąskim predykatem, czy Index Scan przez duży indeks z filtrem dopiero po odczycie.

DECLARE @CustomerID int = 11000;

SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SET STATISTICS XML ON;

SELECT
    soh.SalesOrderID,
    soh.OrderDate,
    soh.TotalDue
FROM Sales.SalesOrderHeader AS soh
WHERE soh.CustomerID = @CustomerID
  AND soh.Status = 5
ORDER BY soh.OrderDate DESC;

SET STATISTICS XML OFF;
SET STATISTICS TIME OFF;
SET STATISTICS IO OFF;

Ten blok daje trzy warstwy informacji: STATISTICS IO pokazuje odczyty logiczne i fizyczne, STATISTICS TIME pokazuje CPU oraz czas całkowity, a STATISTICS XML zwraca rzeczywisty plan XML. W środowisku produkcyjnym uruchamiaj takie pomiary ostrożnie: najlepiej dla jednego zapytania, w oknie diagnostycznym, z parametrami odzwierciedlającymi realny problem. Nie testuj ciężkich raportów na pełnej bazie w godzinach szczytu tylko po to, aby zebrać plan; najpierw sprawdź Query Store i istniejące plany w cache.

Gdy widzisz Key Lookup wykonywany 20 razy, to zwykle nie problem. Gdy widzisz Key Lookup wykonywany 500 000 razy, indeks nieklastrowany prawdopodobnie nie pokrywa zapytania. Gdy widzisz Sort przed TOP (50), sprawdź, czy indeks może obsłużyć predykat i kolejność sortowania jednocześnie. Gdy widzisz Hash Match z dużym Spill Level, problem może wynikać z błędnych statystyk, zbyt małego grantu pamięci albo bardzo dużego zbioru pośredniego. Każda z tych obserwacji powinna prowadzić do konkretnej hipotezy, a nie automatycznej zmiany.

Strategia indeksów: mniej indeksów, ale trafniejszych

Microsoftowy Przewodnik po projektowaniu indeksów programu SQL Server podkreśla, że indeksy projektujesz pod zapytania, a nie pod pojedyncze kolumny. W praktyce oznacza to, że indeks na CustomerID może być poprawny, ale indeks na (CustomerID, Status, OrderDate) z kolumnami INCLUDE może być o wiele lepszy, jeżeli aplikacja stale filtruje po kliencie i statusie, sortuje po dacie i wyświetla kwotę. Kolejność kluczy ma znaczenie: najpierw dajesz kolumny używane w predykatach równości, potem zakresy i sortowanie, a kolumny tylko wyświetlane przenosisz do INCLUDE.

Nie twórz indeksu dla każdej sugestii z planu wykonania. Sugestia missing index widzi jedno zapytanie i nie zna pełnego kosztu utrzymania indeksu, wpływu na zapisy, duplikacji istniejących indeksów oraz tego, czy inne zapytania skorzystają z tej samej struktury. Przed utworzeniem indeksu porównaj go z indeksami istniejącymi. Jeżeli masz indeks (CustomerID), drugi (CustomerID, OrderDate) i trzeci (CustomerID, OrderDate) INCLUDE (TotalDue), prawdopodobnie pierwszy lub drugi można po testach usunąć. Nadmiar indeksów spowalnia zapis i powiększa bazę, a w systemie OLTP to potrafi zaboleć bardziej niż pojedynczy wolny raport.

Dobry indeks pokrywający powinien rozwiązywać konkretny problem. Jeżeli ekran zamówień pobiera ostatnie zapłacone zamówienia klienta, indeks filtrowany może być mniejszy i szybszy niż pełny indeks dla całej tabeli. Jeśli tabela ma 20 milionów wierszy, ale aktywne zadania to tylko 2% danych, indeks filtrowany na Status IN ('Nowe', 'W toku') utrzymuje małą strukturę i lepsze statystyki dla ważnego podzbioru. Jeżeli raport agreguje setki milionów wierszy faktów, rowstore może być niewystarczający i wtedy indeks columnstore staje się realnym narzędziem, nie modnym dodatkiem.

CREATE NONCLUSTERED INDEX IX_SalesOrderHeader_Customer_Status_OrderDate
ON Sales.SalesOrderHeader
(
    CustomerID,
    Status,
    OrderDate DESC
)
INCLUDE
(
    SalesOrderID,
    TotalDue,
    SubTotal,
    TaxAmt
)
WHERE Status = 5
WITH
(
    ONLINE = ON,
    SORT_IN_TEMPDB = ON,
    DATA_COMPRESSION = PAGE
);

To jest produkcyjny wzorzec, ale nie uniwersalna recepta. ONLINE = ON zależy od edycji i scenariusza, SORT_IN_TEMPDB wymaga miejsca w tempdb, a DATA_COMPRESSION = PAGE zmniejsza I/O kosztem CPU. Indeks filtrowany ma sens tylko wtedy, gdy zapytanie zawiera predykat zgodny z filtrem. Po utworzeniu indeksu sprawdź plan, odczyty logiczne i wpływ na zapisy. Jeżeli zapytanie przyspieszyło z 4 sekund do 80 ms, ale import nocny wydłużył się z 20 minut do 2 godzin, musisz zrównoważyć korzyści.

Statystyki: kiedy automatyka nie wystarcza

Statystyki są paliwem optymalizatora. SQL Server używa histogramów i informacji o gęstości danych, aby oszacować, ile wierszy przejdzie przez predykat. Gdy statystyki są nieaktualne, plan może wyglądać logicznie na papierze, ale działać źle w realnym rozkładzie danych. Dokumentacja Statystyki wyjaśnia mechanizm automatycznego tworzenia i aktualizowania statystyk, ale automatyka nie zawsze zdąży po dużym imporcie, archiwizacji, zmianie statusów albo sezonowym wzroście danych.

Typowy przykład: tabela zamówień ma 10 milionów rekordów, a każdego dnia dochodzi 80 000 nowych. Jeśli raport filtruje po bieżącym dniu, histogram statystyki może nie znać jeszcze świeżych wartości albo znać je z małą dokładnością. Optymalizator zaniża liczbę wierszy, wybiera Nested Loops, a zapytanie robi setki tysięcy lookupów. Aktualizacja statystyk z pełnym skanem dla najważniejszej tabeli po dużym załadowaniu danych może być tańsza niż codzienna godzina powolnych raportów.

UPDATE STATISTICS Sales.SalesOrderHeader
    IX_SalesOrderHeader_Customer_Status_OrderDate
WITH FULLSCAN;

UPDATE STATISTICS Sales.SalesOrderDetail
WITH SAMPLE 50 PERCENT;

Nie używaj FULLSCAN bez zastanowienia dla każdej dużej tabeli. Pełny skan daje dokładniejsze statystyki, ale zużywa I/O i czas. Dla krytycznych tabel raportowych może być uzasadniony po nocnym ETL. Dla wielu tabel OLTP wystarczy domyślne próbkowanie albo wyższa próbka wykonywana w oknie serwisowym. Najważniejsze jest to, aby nie traktować EXEC sp_updatestats jako jedynej odpowiedzi na wszystko. Ta procedura jest wygodna, ale precyzyjna aktualizacja statystyk na problematycznym indeksie bywa szybsza i mniej inwazyjna.

Parameter sniffing: rozwiąż konkretny przypadek, nie każdy parametr

Parameter sniffing sam w sobie nie jest błędem. To mechanizm, dzięki któremu SQL Server może utworzyć dobry plan na podstawie realnej wartości parametru. Problem zaczyna się wtedy, gdy rozkład danych jest skrajnie nierówny. Jeden klient ma 20 zamówień, drugi ma 2 miliony. Jedna kategoria produktu ma 30 pozycji, druga ma 300 000. Plan dobry dla małego klienta może być fatalny dla dużego, a plan dobry dla dużego może być zbyt ciężki dla małego. SQL Server 2022 wprowadza Parameter Sensitive Plan Optimization w ramach inteligentnego przetwarzania zapytań, opisanego w dokumentacji Inteligentne przetwarzanie zapytań, ale nadal musisz rozumieć objawy.

Objawem jest duża zmienność czasu tego samego zapytania bez zmiany kodu: raz 50 ms, raz 20 sekund. W planie widzisz jedną wersję skompilowaną dla wartości, która nie pasuje do aktualnych parametrów. Nie zaczynaj od czyszczenia całego plan cache, bo to uderza w całą instancję. Najpierw zidentyfikuj procedurę, parametry i rozkład danych. Potem wybierz najmniej inwazyjne rozwiązanie: osobna ścieżka kodu dla dużych klientów, OPTION (RECOMPILE) dla rzadkiego raportu, OPTIMIZE FOR dla stabilnego wzorca albo Query Store plan forcing, jeśli dobry plan jest znany i powtarzalny.

CREATE OR ALTER PROCEDURE Sales.usp_GetCustomerOrders
    @CustomerID int,
    @DateFrom date,
    @DateTo date
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        soh.SalesOrderID,
        soh.OrderDate,
        soh.Status,
        soh.TotalDue
    FROM Sales.SalesOrderHeader AS soh
    WHERE soh.CustomerID = @CustomerID
      AND soh.OrderDate >= @DateFrom
      AND soh.OrderDate < DATEADD(day, 1, @DateTo)
    ORDER BY soh.OrderDate DESC
    OPTION (RECOMPILE);
END;

OPTION (RECOMPILE) jest dobre dla zapytań uruchamianych rzadziej, z mocno zmiennymi parametrami, gdy koszt kompilacji jest mały wobec kosztu złego planu. Nie stosuj go mechanicznie w procedurze wykonywanej tysiące razy na minutę, bo możesz przenieść problem z I/O na CPU. W systemach o dużym ruchu czasem lepsza jest rozdzielona logika: osobne zapytanie dla dużych klientów, osobne dla typowych. To mniej eleganckie niż jeden uniwersalny SELECT, ale w produkcji przewidywalność często jest ważniejsza niż akademicka czystość.

Najczęstsze antywzorce w sql query optimization

Wolne zapytania często wynikają z kilku powtarzalnych błędów. Pierwszy to funkcja na kolumnie w predykacie. Warunek WHERE CONVERT(date, OrderDate) = @OrderDate zmusza SQL Server do przeliczenia wartości i może uniemożliwić efektywne użycie indeksu po OrderDate. Lepszy jest zakres: od początku dnia do początku następnego dnia. Drugi antywzorzec to SELECT * w aplikacji. Pobierasz kolumny, których ekran nie pokazuje, zwiększasz transfer, niszczysz szansę na indeks pokrywający i wymuszasz większe granty pamięci.

Trzeci błąd to niejawna konwersja typów. Jeżeli kolumna ma typ nvarchar, a parametr aplikacji przychodzi jako varchar, albo kolumna ma int, a porównujesz ją do tekstu, plan może dostać ostrzeżenie Implicit Conversion. Taka konwersja potrafi zmienić seek w scan, szczególnie gdy SQL Server musi przeliczyć kolumnę, a nie parametr. Czwarty błąd to paginacja przez duże przesunięcie. OFFSET 500000 ROWS FETCH NEXT 50 ROWS ONLY nadal wymaga dojścia do pół miliona wierszy. Dla aplikacji przewijającej listy lepsza bywa paginacja po kluczu: pamiętasz ostatnią datę i identyfikator, a następna strona pobiera wiersze mniejsze lub większe od tego punktu.

DECLARE @OrderDate date = '2026-04-01';

SELECT
    soh.SalesOrderID,
    soh.OrderDate,
    soh.TotalDue
FROM Sales.SalesOrderHeader AS soh
WHERE soh.OrderDate >= @OrderDate
  AND soh.OrderDate < DATEADD(day, 1, @OrderDate)
ORDER BY soh.OrderDate, soh.SalesOrderID;

Ten zapis jest bardziej przyjazny dla indeksu niż funkcja na kolumnie. Jeśli masz indeks po (OrderDate, SalesOrderID), silnik może wykonać seek po zakresie i zwrócić dane w oczekiwanej kolejności. To właśnie jest praktyczna optymalizacja: nie tylko "dodaj indeks", ale "napisz predykat tak, aby indeks miał sens". Developerzy powinni traktować takie reguły jak część standardu kodowania, bo najtańszy tuning to ten wykonany przed wdrożeniem.

Konserwacja indeksów bez rytuałów

Fragmentacja indeksów jest realna, ale w wielu firmach bywa przeceniana. Cotygodniowa przebudowa wszystkich indeksów, niezależnie od rozmiaru i użycia, generuje I/O, log transakcyjny, obciążenie tempdb i czas backupów logu. W nowoczesnym środowisku częściej wygrywa konserwacja selektywna: przebudowujesz albo reorganizujesz tylko te indeksy, które są duże, używane i faktycznie pofragmentowane. Mały indeks liczący kilkadziesiąt stron może mieć 90% fragmentacji i nie mieć żadnego znaczenia dla wydajności.

Przed pracami konserwacyjnymi sprawdź użycie indeksów. Indeks, którego nikt nie czyta, ale który jest aktualizowany przy każdym zapisie, jest kandydatem do usunięcia po analizie zależności. Nie usuwaj indeksów tylko na podstawie jednego dnia metryk, bo mogły obsługiwać raport miesięczny albo proces kwartalny. Zbieraj dane przez pełny cykl biznesowy. W SMB często wystarczy 30-45 dni obserwacji, ale dla księgowości, rozliczeń i magazynu weź pod uwagę koniec miesiąca oraz inwentaryzacje.

SELECT
    OBJECT_SCHEMA_NAME(i.object_id) AS schema_name,
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    i.type_desc,
    s.user_seeks,
    s.user_scans,
    s.user_lookups,
    s.user_updates
FROM sys.indexes AS i
LEFT JOIN sys.dm_db_index_usage_stats AS s
    ON s.object_id = i.object_id
   AND s.index_id = i.index_id
   AND s.database_id = DB_ID()
WHERE i.object_id > 0
  AND i.is_hypothetical = 0
ORDER BY s.user_updates DESC, s.user_seeks ASC;

To zapytanie nie mówi automatycznie "usuń indeks". Pokazuje kandydatów do rozmowy: dużo aktualizacji, mało odczytów, potencjalna duplikacja. Zanim usuniesz indeks, sprawdź definicję, zależności, plany najważniejszych zapytań i historię użycia. Bezpieczna praktyka to najpierw wyłączyć indeks w środowisku testowym, uruchomić zestaw najważniejszych zapytań, a dopiero potem planować zmianę produkcyjną. W produkcji usunięcie indeksu powinno mieć plan cofnięcia: skrypt CREATE INDEX, okno serwisowe i monitoring po wdrożeniu.

tempdb, pamięć i równoległość: gdy problem nie jest w jednym SELECT

Czasem zapytanie wygląda poprawnie, indeksy są rozsądne, statystyki aktualne, a baza nadal zwalnia. Wtedy sprawdzasz warstwę zasobów. tempdb obsługuje sortowania, hashe, wersjonowanie wierszy, tabele tymczasowe i wiele operacji wewnętrznych. Jeżeli widzisz częste spill do tempdb, wysokie oczekiwania związane z I/O albo konflikty alokacji, problem może wymagać poprawy planu, zwiększenia pamięci, lepszej konfiguracji plików tempdb albo ograniczenia raportów uruchamianych równolegle.

Pamięć SQL Server kontrolujesz ustawieniem max server memory. Nie zostawiaj całej pamięci systemu dla silnika, bo Windows, agenty backupu, antywirus, sterowniki i usługi pomocnicze też potrzebują RAM. Dla serwera dedykowanego SQL Server zwykle rezerwujesz część pamięci dla systemu i pozostałych usług, a resztę przekazujesz instancji. Jeśli na jednym hoście działa kilka instancji, ustaw limity jawnie dla każdej z nich. Brak limitów może sprawić, że jedna instancja wypchnie drugą lub system operacyjny zacznie działać niestabilnie.

Równoległość wymaga osobnej uwagi. MAXDOP i cost threshold for parallelism wpływają na to, kiedy SQL Server rozbije zapytanie na wiele wątków. Zbyt niskie progi powodują, że wiele średnich zapytań konkuruje o CPU. Zbyt wysokie mogą utrudnić duże raporty. W środowisku SMB nie kopiuj ustawień z przypadkowego forum. Zacznij od zaleceń Microsoft, obserwuj CXPACKET, CXCONSUMER, CPU i czasy raportów, a zmiany wprowadzaj pojedynczo. Jeżeli po zmianie nie umiesz powiedzieć, jaki wskaźnik ma się poprawić, zmiana jest zgadywaniem.

Lista kontrolna wdrożenia poprawki wydajnościowej

Każda poprawka wydajnościowa powinna przejść przez ten sam minimalny proces. Najpierw zapisujesz stan bazowy: czas wykonania, odczyty logiczne, CPU, plan, parametry, liczbę wierszy i obciążenie serwera. Następnie przygotowujesz zmianę w środowisku testowym na danych możliwie podobnych do produkcji. Potem porównujesz wyniki, ale nie tylko dla jednego zapytania. Indeks, który przyspiesza SELECT, może spowolnić INSERT. Zmiana procedury może poprawić przypadek typowy i pogorszyć przypadek graniczny. Aktualizacja statystyk może zmienić plany innych zapytań.

Przed wdrożeniem produkcyjnym przygotuj skrypt wykonania i skrypt cofnięcia. Dla indeksu cofnięciem może być DROP INDEX albo odtworzenie poprzedniej definicji. Dla procedury składowanej trzymaj poprzednią wersję definicji. Dla wymuszenia planu w Query Store miej skrypt usunięcia wymuszenia. Ustal także okno obserwacji po wdrożeniu: pierwsze 15 minut, pierwsza godzina, koniec dnia i następny poranek. Wydajność bazy zmienia się w rytmie biznesu, więc poprawka wdrożona o 14:00 może wyglądać dobrze, ale prawdziwy test przyjdzie o 8:00, gdy wszyscy zalogują się do systemu.

W firmach bez dedykowanego DBA warto stworzyć prosty rejestr zmian wydajnościowych. Zapisz datę, problem, zapytanie, plan przed, zmianę, wynik po i osobę odpowiedzialną. Po kilku miesiącach taki rejestr jest bezcenny, bo pokazuje, dlaczego istnieje dany indeks, czemu procedura ma OPTION (RECOMPILE) i jakie raporty były krytyczne dla biznesu. Bez tej dokumentacji kolejna osoba może usunąć "dziwny" indeks, który rozwiązywał problem zamknięcia miesiąca.

Macierz typów oczekiwań (Wait Types) i rekomendacje naprawcze

Poniższa tabela przedstawia najczęściej spotykane typy oczekiwań w SQL Server oraz sugerowane działania naprawcze. Pamiętaj, że jest to punkt wyjścia, a każdy przypadek może wymagać głębszej analizy.