Kompatybilność trybu optymalizatora

Kompatybilność trybu optymalizatora określa, według której generacji reguł silnik dobiera sposób wykonania zapytania.

Kompatybilność trybu optymalizatora w SQL Server

Kompatybilność trybu optymalizatora w SQL Server określa, z którego zestawu reguł i zachowań optymalizatora zapytań ma korzystać silnik podczas tworzenia planu wykonania. Ustawienie jest powiązane z poziomem zgodności bazy danych, czyli database compatibility level. Nie zmienia ono wersji samego silnika SQL Server ani formatu plików bazy. Wskazuje natomiast, z jaką generacją funkcji języka T-SQL oraz mechanizmów optymalizacji ma być zgodna dana baza.

W praktyce oznacza to, że po podniesieniu poziomu zgodności to samo zapytanie może otrzymać inny plan wykonania, mimo że jego tekst, indeksy i dane pozostają bez zmian. Optymalizator może inaczej oszacować liczbę wierszy, wybrać inną kolejność złączeń, zastosować odmienny sposób agregacji albo zmienić decyzję dotyczącą użycia indeksu. Zmiana nie jest więc wyłącznie deklaracją administracyjną. Może wpływać na czas wykonywania zapytań i zużycie zasobów procesora, pamięci oraz operacji wejścia-wyjścia.

Poziom zgodności a generacja planu wykonania

SQL Server przypisuje poziom zgodności do konkretnej bazy danych. Przykładowe wartości używane w kolejnych generacjach silnika to 110, 120, 130, 140, 150, 160 i 170, przy czym dostępność danej wartości zależy od wersji SQL Server. Poziom 150 jest związany z SQL Server 2019, poziom 160 z SQL Server 2022, a poziom 170 z SQL Server 2025. Sama obecność nowszej wersji serwera nie oznacza automatycznego przełączenia wszystkich istniejących baz na najwyższy poziom.

Poziom można odczytać z widoku katalogowego sys.databases, sprawdzając kolumnę compatibility_level. W SQL Server używa się do tego zapytania SELECT name, compatibility_level FROM sys.databases;. Zmiana ustawienia wykonywana jest poleceniem ALTER DATABASE, na przykład ALTER DATABASE [NazwaBazy] SET COMPATIBILITY_LEVEL = 160;. Przed zastosowaniem zmiany trzeba potwierdzić, że wskazana wartość jest obsługiwana przez zainstalowany silnik i że aplikacja korzysta z konstrukcji zgodnych z wybranym poziomem.

Poziom zgodności wpływa również na zachowanie estymatora liczności, czyli mechanizmu przewidującego, ile wierszy zwróci określony etap zapytania. Błędne oszacowanie może prowadzić do wyboru niekorzystnego planu: na przykład do zastosowania skanowania dużej tabeli zamiast wyszukania po indeksie albo do przydzielenia zbyt małej ilości pamięci dla sortowania. Zmiana trybu optymalizatora nie naprawia automatycznie brakujących indeksów, nieaktualnych statystyk ani niepoprawnych predykatów w zapytaniu, ale może zmienić sposób, w jaki te informacje są interpretowane.

Skutki zmiany dla istniejących zapytań

Najważniejszym skutkiem przełączenia poziomu zgodności jest możliwość ponownej kompilacji planów zapytań. Plan jest tworzony na podstawie tekstu zapytania, parametrów, statystyk, indeksów, ustawień bazy i innych właściwości środowiska wykonawczego. Po zmianie poziomu zgodności SQL Server może uznać, że wcześniejszy plan nie powinien być dalej używany, a następnie opracować nowy plan zgodny z aktualnym zestawem reguł optymalizacji.

Nowy plan może poprawić wydajność jednych zapytań, ale pogorszyć działanie innych. Szczególnie wrażliwe są zapytania z wieloma złączeniami, filtrami zależnymi od parametrów, nierównomiernym rozkładem wartości oraz tabelami o szybko zmieniającej się liczności. Różnice mogą ujawnić się dopiero dla określonych wartości parametrów, dlatego pojedynczy udany test nie potwierdza poprawności całej zmiany. Porównanie powinno obejmować rzeczywiste czasy wykonania, liczbę odczytanych stron, liczbę zwróconych wierszy, wykorzystanie pamięci i operacji procesora.

SQL Server udostępnia Query Store, który może pomóc porównać plany oraz statystyki wykonania zapytań przed zmianą i po niej. W przypadku regresji należy najpierw ustalić, czy przyczyną jest nowy plan, zmiana statystyk, inny rozkład danych albo problem z parametryzacją. Samo wymuszenie wcześniejszego planu nie powinno zastępować analizy, ponieważ stary plan może przestać być właściwy po zmianie danych lub indeksów. W uzasadnionych przypadkach można rozważyć kontrolowane użycie mechanizmów Query Store do wymuszenia planu, ale wymaga to obserwacji późniejszego zachowania zapytania.

Bezpieczna weryfikacja kompatybilności trybu optymalizatora

Weryfikację warto rozpocząć od ustalenia wersji SQL Server, poziomu zgodności każdej używanej bazy oraz listy zapytań o największym znaczeniu dla aplikacji. Następnie należy sprawdzić plany wykonania i statystyki zapytań przy dotychczasowym ustawieniu. Przed zmianą powinny być dostępne kopie zapasowe oraz możliwość odtworzenia poprzedniej konfiguracji. Zmiana poziomu zgodności jest ustawieniem bazy danych, dlatego nie należy testować jej bezpośrednio na środowisku, na którym działa krytyczne obciążenie, bez wcześniejszej kontroli wpływu na aplikację.

Po przełączeniu poziomu trzeba obserwować zapytania, które mają największy udział w czasie procesora, odczytach logicznych i czasie oczekiwania. Szczególną uwagę należy zwrócić na rozbieżność między estymowaną a rzeczywistą liczbą wierszy w planie. Duża różnica może wskazywać na nieaktualne statystyki, nietypowy rozkład danych lub zapytanie, którego predykaty utrudniają prawidłową estymację. Warto także sprawdzić, czy aplikacja nie wykorzystuje składni lub zachowania zależnego od starszego poziomu zgodności.

Jeżeli po zmianie pojawi się regresja, można tymczasowo przywrócić wcześniejszy poziom zgodności poleceniem ALTER DATABASE, o ile nadal jest obsługiwany przez daną wersję SQL Server. Przywrócenie ustawienia nie wyjaśnia jednak przyczyny problemu. Trwała decyzja powinna wynikać z porównania planów, statystyk i rzeczywistego obciążenia, a nie tylko z obserwacji jednego zapytania uruchomionego w narzędziu administracyjnym.