Optymalizacja zapytań T-SQL: Praktyczny przewodnik po wydajności

Wolne zapytanie SQL Server zazwyczaj nie pojawia się z jasnym wyjaśnieniem. Trafia na produkcję jako pulpit nawigacyjny, w którym upływa limit czasu, procedura składowana, która wcześniej działała dobrze, lub raport, który kończy się niepowodzeniem tylko wtedy, gdy trafi na odpowiedniego klienta lub zakres dat. Dlatego optymalizacja zapytań tsql działa najlepiej, gdy zaczyna się od dowodów, a nie od przepisywania kodu.

Spis treści

• Rozpoczęcie od diagnostyki przed przepisaniem czegokolwiek

  • Najpierw punkt odniesienia, potem modyfikacja SQL

  • Zmieniaj tylko jedną rzecz na raz

• Odczytywanie planów wykonania i zrozumienie zachowania optymalizatora

  • Czytaj plan od liści w górę

  • Szacowane wiersze a rzeczywiste wiersze

• Przepisywanie zapytań z użyciem wzorców zbiorowych i wczesnego filtrowania

  • Spraw, aby silnik przetwarzał mniej danych

  • Używaj celów wierszy (row goals) i wskazówek z umiarem

• Projektowanie indeksów i strategie utrzymania statystyk

  • Projektuj pod kątem zapytania, które faktycznie uruchamiasz

  • Dbaj o to, aby statystyki były wystarczająco świeże, by móc im zaufać

• Rozwiązywanie problemów z parameter sniffing i wymuszaniem planów

  • Kiedy problemem jest plan w pamięci podręcznej

  • Wybierz rozwiązanie pasujące do trybu awarii

• Radzenie sobie z presją pamięci i ograniczeniami zasobów platformy

  • Oddziel lokalny koszt zapytania od presji na współdzielone zasoby

  • Przejdź do planowania pojemności, gdy wymaga tego obciążenie pracą

• Wdrażanie ciągłego monitorowania z Observability wewnątrz bazy danych

  • Obserwuj odchylenia, zanim zrobią to użytkownicy

  • Użyj observability, aby zamknąć pętlę

Rozpoczęcie od diagnostyki przed przepisaniem czegokolwiek

Najszybszym sposobem na marnowanie czasu jest zmiana SQL, zanim dowiesz się, co działa wolno. Na produkcji zapytanie może wyglądać na winne, podczas gdy problemem jest współdzielona rywalizacja o zasoby, nieaktualne statystyki lub zły plan zapisany w pamięci podręcznej z innej wartości parametru. Dyscyplinowane podejście do dostrajania zaczyna się od przechwycenia dokładnego obciążenia roboczego, w tym rzeczywistych parametrów, oraz zmierzenia zapytania przed wprowadzeniem jakichkolwiek zmian.

Najpierw punkt odniesienia, potem modyfikacja SQL

Punkt odniesienia nie jest opcjonalny. Praktyczna pętla dostrajania zaczyna się od czasu wykonania, odczytów logicznych i procesora, a następnie przechwytuje plan i otaczające obciążenie pracą, aby można było ocenić, czy zmiana pomogła, czy tylko przeniosła koszt w inne miejsce – co jest tym samym przepływem pracy zalecanym w podręcznikach dostrajania SQL Server, ponieważ pozwala zachować widoczność związku przyczynowo-skutkowego (tuning workflow guidance).

Praktyczna zasada: jeśli nie potrafisz wyjaśnić wąskiego gardła operatora przed przepisaniem kodu, prawdopodobnie nie rozumiesz jeszcze problemu.

Jest to szczególnie ważne, gdy objawem jest wolny czas reakcji, ale przyczyna leży poza tekstem instrukcji. Analiza oczekiwań na poziomie serwera, korelacja kolejek, a następnie inspekcja na poziomie bazy danych lub zapytania to kolejność, która pozwala uniknąć zajmowania się niewłaściwą rzeczą, ponieważ obciążenie pracą może być blokowane przez operacje we/wy, pamięć lub presję współbieżności, zanim w ogóle dotrze do kandydata do przepisania (instance-to-query tuning sequence).

Zmieniaj tylko jedną rzecz na raz

Dostrajanie jednej zmiennej na raz brzmi powoli, ale to jedyny sposób, aby zaufać wynikom. Jeśli w tym samym kroku zmienisz tekst zapytania, indeks i zaktualizujesz statystyki, nie będziesz wiedzieć, która dźwignia miała znaczenie. Co gorsza, przepisanie kodu może poprawić odczyty logiczne, zwiększając jednocześnie zużycie procesora lub czyniąc plan bardziej podatnym na uszkodzenia przy innym zestawie parametrów.

Dobry przepływ pracy wygląda następująco:

• Przechwyć dokładny tekst zapytania i parametry. Ta sama procedura składowana może zachowywać się bardzo różnie przy różnych danych wejściowych.

• Znajdź operator będący wąskim gardłem. Sortowanie, skanowanie i wyszukiwanie kluczy (key lookups) to często miejsca, w których kumulują się koszty.

• Zastosuj jedną ukierunkowaną zmianę. Następnie uruchom ponownie to samo obciążenie w tych samych warunkach.

• Porównaj z punktem odniesienia. Ponownie sprawdź odczyty, procesor i czas, który upłynął, przed przejściem dalej.

Ta metoda brzmi prosto, ponieważ taka jest. Trudność polega na opieraniu się pokusie „naprawiania” wszystkiego na raz. Jeśli zapytanie naprawdę cierpi z powodu rywalizacji o współdzielone zasoby, pierwsza przydatna poprawka może znajdować się poza samym zapytaniem, dlatego doświadczeni administratorzy baz danych nie traktują tekstu SQL jako jedynego miejsca, w którym należy szukać pomocy.

Odczytywanie planów wykonania i zrozumienie zachowania optymalizatora

Złe zapytanie często wygląda dobrze w edytorze tekstu, a i tak przestaje działać w czasie wykonywania. SQL Server nie wykonuje instrukcji w kolejności, w jakiej zostały napisane. Optymalizator opiera się na kosztach i jest napędzany statystykami, więc ocenia możliwe plany, szacuje liczbę wierszy i wybiera ścieżkę, która jego zdaniem będzie kosztować najmniej (cost-based optimizer overview). W optymalizacji zapytań tsql sprawia to, że czytanie planu jest pierwszą prawdziwą umiejętnością diagnostyczną, a nie tylko kosmetycznym dodatkiem.

Czytaj plan od liści w górę

Zacznij od liści, nie od korzenia. Operatory liści pokazują, gdzie wiersze wchodzą do planu, a najdroższy liść, często ten o najwyższym koszcie iloczynu pętli i czasu, zazwyczaj wskazuje pierwsze miejsce, w którym plan idzie nie tak. Jeśli skanowanie zasila złączenie, a następnie sortowanie, skanowanie jest często głównym problemem, nawet gdy sortowanie dominuje w czasie, który upłynął.

Ten nawyk czytania staje się bardziej przydatny, gdy połączysz go z danymi wejściowymi optymalizatora. DBCC SHOW_STATISTICS ujawnia statystyki używane przez SQL Server dla tabeli lub widoku indeksowanego, w tym STAT_HEADER, DENSITY_VECTOR oraz HISTOGRAM (Microsoft documentation). Obiekty te mają znaczenie, ponieważ optymalizator dokonuje oszacowania kardynalności przed ustaleniem planu. Informacje o gęstości są szczególnie przydatne przy filtrach wielokolumnowych na tej samej tabeli, gdzie prosta intuicja dotycząca liczby wierszy często zawodzi.

Jeśli plan wygląda podejrzanie, porównuję go z praktyczną listą kontrolną dostrajania, taką jak how to optimize SQL queries with execution plan analysis. Tego rodzaju krok pozwala oprzeć analizę na rzeczywistych operatorach, a nie tylko na domysłach dotyczących tekstu zapytania.

Szacowane wiersze a rzeczywiste wiersze

Pierwszą rzeczą, którą sprawdzam w złym planie, jest rozbieżność między szacowaną a rzeczywistą liczbą wierszy. Gdy te liczby znacznie się różnią, optymalizator pracuje na zniekształconym obrazie, a reszta planu jest zazwyczaj budowana na tym błędzie. Artykuł z VLDB z 2025 r. wykazał, że błędy szacowania kardynalności są powszechne i często stanowią dominujący czynnik stojący za słabymi planami (VLDB 2025 paper), co pokrywa się z tym, co dzieje się na produkcji, gdy niesymetryczne rozkłady lub skorelowane predykaty kierują silnik w stronę niewłaściwego złączenia lub metody dostępu.

Jeśli optymalizator uważa, że nadchodzi 10 wierszy, a faktycznie dociera 10 000, plan nie jest nieco błędny – on rozwiązuje niewłaściwy problem.

Właśnie dlatego nieaktualne statystyki zasługują na uwagę na wczesnym etapie. Świeże statystyki nie gwarantują idealnego planu, ale nieaktualne sprawiają, że złe oszacowanie jest o wiele bardziej prawdopodobne. W przypadku tabel zoptymalizowanych pod kątem pamięci firma Microsoft zauważa, że optymalizator nadal utrzymuje statystyki kolumn klucza indeksu i może w razie potrzeby tworzyć dodatkowe statystyki dla kolumn niebędących kluczami, więc te obciążenia pracą nadal zależą od tego samego obrazu kardynalności.

Przepisywanie zapytań z użyciem wzorców zbiorowych i wczesnego filtrowania

Gdy wąskie gardło jest realne i widoczne, przepisz SQL w ściśle określonym celu. Zmiany o najwyższej wartości to zazwyczaj te, które zmniejszają ilość danych, jakie silnik musi przetworzyć, a nie te, które sprawiają, że zapytanie wygląda na sprytne. Wczesne filtrowanie, rzutowanie mniejszej liczby kolumn i utrzymywanie predykatów w postaci sargable – wszystko to pomaga optymalizatorowi efektywniej korzystać z indeksów oraz zmniejsza presję na we/wy i pamięć (optimization techniques guide).

Spraw, aby silnik przetwarzał mniej danych

Najprostsze sukcesy to często te, które zespoły pomijają, ponieważ wydają się zbyt podstawowe. Unikaj SELECT *, gdy zapytanie nie potrzebuje każdej kolumny, ponieważ dodatkowe rzutowane kolumny poszerzają wiersze i zwiększają operacje we/wy. Umieszczaj selektywne filtry w klauzuli WHERE przed złączeniami, jeśli to możliwe, ponieważ zmniejsza to wolumen złączeń, który silnik musi przenieść przez resztę planu.

Kilka wzorców ma kluczowe znaczenie:

• Używaj predykatów sargable. Jeśli predykat nie może być efektywnie dopasowany do indeksu, optymalizator ma mniejsze pole manewru.

• Preferuj UNION ALL, gdy duplikaty nie muszą być usuwane. UNION dodaje dodatkową pracę związaną z sortowaniem lub deduplikacją.

• Ogranicz podzapytania, które tylko przeformatowują dane. Zagnieżdżona logika, która nie zmniejsza liczby wierszy, często dodaje narzut bez pomocy dla planu.

• Dopasuj indeksy do rzeczywistych filtrów. Ukierunkowany indeks pomaga, gdy pokrywa się ze ścieżką dostępu, z której korzysta zapytanie.

Dobre przepisanie kodu zmniejsza nakład pracy, który optymalizator musi wziąć pod uwagę, a nie tylko liczbę linii SQL, które trzeba przeczytać.

Używaj celów wierszy (row goals) i wskazówek z umiarem

Microsoft dokumentuje wskazówki dotyczące zapytań (query hints), które mogą zmieniać zachowanie wykonania, w tym zachowanie celów wierszy (row-goal), gdzie po zwróceniu pierwszej określonej liczby wierszy zapytanie nadal działa, aby wygenerować pełny zestaw wyników (query hints documentation). Może to być przydatne, gdy szybkie uzyskanie początkowych wyników jest ważniejsze niż całkowita przepustowość, ale zmienia to kompromisy optymalizatora. Plan, który jest świetny dla małego zestawu wyników, może być złym wyborem dla dużego.

Właśnie dlatego traktuję wskazówki jako korektę na ostatnim etapie, a nie jako pierwszą reakcję. Jeśli zapytanie nadal działa wolno po wczesnym filtrowaniu i oczyszczeniu opartym na zbiorach, kolejne pytanie zazwyczaj brzmi, czy ścieżka dostępu nie kłóci się z kształtem danych lub statystykami, które za nimi stoją.

Projektowanie indeksów i strategie utrzymania statystyk

Indeksy to nie są magiczne przełączniki wydajności. Są danymi wejściowymi do modelu kosztów optymalizatora i pomagają tylko wtedy, gdy pasują do wzorca zapytania i rozkładu danych. Jeśli ścieżka dostępu nie pasuje do sposobu, w jaki zapytanie filtruje, łączy lub rzutuje kolumny, silnik nadal może wybrać skanowanie, plan z dużą liczbą wyszukiwań (lookups) lub sortowanie zrzucane na dysk (spill-prone sort).

Projektuj pod kątem zapytania, które faktycznie uruchamiasz

Najlepszy indeks w teorii i najlepszy indeks na produkcji rzadko są tym samym. W praktyce potrzebujesz indeksów, które pasują do najdroższych i powtarzalnych wzorców dostępu, zwłaszcza filtrów pojawiających się w najwolniejszych zapytaniach. Indeks pokrywający (covering index) może wyeliminować wyszukiwanie kluczy (key lookups), gdy zapytanie potrzebuje małego, stabilnego zestawu kolumn, ale może również dodać narzut przy zapisie i koszt przechowywania, więc projekt wymaga analizy rzeczywistego obciążenia, a nie domysłów.

Model statystyk Microsoftu ma tutaj znaczenie, ponieważ optymalizator szacuje kardynalność na podstawie tych obiektów przed wyborem planu (DBCC SHOW_STATISTICS). Jeśli statystyki są nieaktualne, nawet dobrze zbudowany indeks może zostać zignorowany lub niewłaściwie użyty. Dlatego dobre projektowanie indeksów i dobra konserwacja statystyk idą w parze.

Dbaj o to, aby statystyki były wystarczająco świeże, by móc im zaufać

Konserwacja statystyk to nie tylko porządki, to część dbałości o jakość planu. Gdy rozkłady wierszy się zmieniają, optymalizator może nadal uważać, że tabela wygląda tak, jak wczoraj lub w zeszłym miesiącu, a ten nieaktualny obraz może prowadzić do złych decyzji dotyczących złączeń, słabych metod dostępu i nieoczekiwanego zużycia pamięci. W przypadku tabel zoptymalizowanych pod kątem pamięci firma Microsoft nadal utrzymuje statystyki kolumn kluczowych indeksu i może w razie potrzeby dodawać kolejne dla kolumn niebędących kluczami, co pokazuje, jak kluczowe znaczenie mają statystyki w różnych modelach przechowywania.

Praktyczne podejście do konserwacji jest proste:

• Aktualizuj statystyki, gdy wydajność planów spada. Nie czekaj, aż problem stanie się systemowy.

• Obserwuj powtarzające się wzorce wyszukiwania kluczy (key lookup). Często pokazują one, gdzie pomógłby indeks pokrywający.

• Używaj przebudowy i reorganizacji z konkretnego powodu. Konserwacja powinna wspierać obciążenie pracą, a nie odbywać się na autopilocie.

• Regularnie przeglądaj użycie indeksów. Indeks, który wydawał się mądrym wyborem sześć miesięcy temu, teraz może być tylko zbędnym balastem.

Sugestie dotyczące brakujących indeksów mogą pomóc w dostrzeżeniu oczywistych luk, ale same w sobie nie stanowią strategii projektowania. Traktuję je jako wskazówki, a następnie porównuję z obciążeniem pracą i kosztami konserwacji. Optymalizator może wybierać tylko z kształtów, które mu dostarczysz, a nieaktualne statystyki mogą sprawić, że nawet dobry kształt będzie wyglądał źle.

Rozwiązywanie problemów z parameter sniffing i wymuszaniem planów

Niektóre z najgorszych niespodzianek produkcyjnych w ogóle nie dotyczą tekstu zapytania. Dzieją się tak, ponieważ ta sama procedura składowana otrzymuje bardzo różne plany w zależności od pierwszej wartości parametru, jaką widzi optymalizator, a następnie ten plan jest ponownie używany przy kolejnych wywołaniach, które nie pasują do pierwotnego kształtu. Właśnie dlatego zachowanie parameter-sensitive plan behavior znajduje się na samej górze każdego poważnego podręcznika optymalizacji zapytań tsql.

Kiedy problemem jest plan w pamięci podręcznej

Wskazówki Microsoftu dotyczące Azure SQL wyraźnie wskazują na RECOMPILE, OPTIMIZE FOR, OPTIMIZE FOR UNKNOWN, wymuszanie planu i dzielenie procedur jako ukierunkowane środki zaradcze, gdy jedno zapytanie działa dobrze dla niektórych wartości parametrów, a źle dla innych (Microsoft training guidance). Ma to znaczenie, ponieważ tekst zapytania może być w porządku, ale buforowany plan może być nieodpowiedni dla bieżącego obciążenia.

Praktyczny objaw jest dobrze znany. Procedura działa błyskawicznie dla jednego klienta, wlecze się dla innego i przełącza się tam i z powrotem po zmianach w pamięci podręcznej lub restartach. W takim przypadku problem optymalizacji polega w rzeczywistości na kontrolowaniu zmienności planu, a nie na przepisywaniu idealnie czytelnego zapytania w coś niemożliwego do utrzymania.

Wybierz rozwiązanie pasujące do trybu awarii

RECOMPILE jest przydatne, gdy zapytanie potrzebuje planu dostosowanego do bieżących parametrów, a narzut jest akceptowalny. OPTIMIZE FOR jest lepsze, gdy znasz reprezentatywną wartość i chcesz nakierować plan na nią. OPTIMIZE FOR UNKNOWN może być bezpieczniejszą drogą środka, gdy żadna pojedyncza wartość parametru nie odzwierciedla dobrze obciążenia roboczego. Wymuszanie planu pomaga, gdy zidentyfikowano już kształt planu, który zachowuje się stabilnie.

Właściwym rozwiązaniem dla parameter sniffing nie zawsze jest lepszy indeks. Czasami jest to bardziej uczciwy wybór planu.

Nowsze mechanizmy kontroli operacyjnej również mają znaczenie. Nowoczesne wskazówki firmy Microsoft obejmują DISABLE_RESULT_SET_CACHE, co pokazuje, że dostrajanie zapytań musi teraz uwzględniać zachowanie pamięci podręcznej, a także indeksowanie i przepisywanie kodu. To przydatne przypomnienie, że niespójna wydajność często wynika z interakcji między danymi, pamięcią podręczną i wartościami parametrów, a nie tylko z samego SQL.

Radzenie sobie z presją pamięci i ograniczeniami zasobów platformy

Zapytanie może być dobrze napisane, poprawnie zaindeksowane, a mimo to działać wolno. Gdy tak się dzieje, wąskim gardłem często okazuje się presja pamięci, zrzucanie danych na dysk (spill-to-disk) lub szersze ograniczenia platformy, a nie sam tekst zapytania. Wiele przewodników po dostrajaniu pomija tę rzeczywistość, mimo że często jest to powód, dla którego „naprawione” zapytanie nadal rozczarowuje.

Oddziel lokalny koszt zapytania od presji na współdzielone zasoby

Zacznij od analizy oczekiwań (wait analysis) i monitorowania zasobów, zanim obwinisz pojedynczą instrukcję. Zapytanie, które zrzuca dane na dysk, rywalizuje o przydziały pamięci (memory grants) lub napotyka na rywalizację w tempdb, może wyglądać jak zły kandydat do przepisania, podczas gdy głębszym problemem jest presja na system. Wskazówki firmy Microsoft dotyczące przetwarzania zapytań i observability w Azure SQL kierują w stronę takich narzędzi jak monitorowanie zasobów, Database Watcher, Query Performance Insights oraz metryki wydajności Fabric, aby sprawdzić, czy obciążenie nie jest ograniczane przez samą platformę (platform observability guidance).

Jeśli cała instancja jest pod presją, lokalne przepisanie SQL może wydawać się nieskuteczne, nawet jeśli robi dokładnie to, co powinno.

Właśnie dlatego typy oczekiwań (wait types) mają znaczenie. Pokazują one, czy wąskim gardłem jest nasycenie procesora, opóźnienie we/wy, blokady współbieżności, czy coś zupełnie innego. Zapytanie, które zmniejsza liczbę odczytów logicznych, ale nadal zrzuca dane na dysk, może poprawić jedną liczbę, pozostawiając wrażenia użytkownika niemal bez zmian.

Przejdź do planowania pojemności, gdy wymaga tego obciążenie pracą

W pewnym momencie dostrajanie zapytań przestaje być odpowiednim narzędziem. Jeśli obciążenie pracą stale walczy z ograniczeniami pamięci, pamięci masowej lub współbieżności, rozwiązaniem może być planowanie pojemności, izolacja obciążenia lub przeprojektowanie platformy, a nie kolejne przepisanie kodu. Na tym polega praktyczna różnica między rozwiązywaniem problemu na poziomie instrukcji a rozwiązywaniem problemu na poziomie systemu.

Dla zespołów pracujących w środowiskach zarządzanych to rozróżnienie ma jeszcze większe znaczenie, ponieważ platforma może ukrywać część podstawowej presji, dopóki obciążenie nie stanie się bardzo intensywne. Jeśli Twoje poprawki stale zmniejszają koszty zapytania o mały ułamek, ale użytkownicy nadal odczuwają spowolnienie, kolejnym pytaniem nie jest to, który SQL zmodyfikować, ale to, jaki współdzielony zasób jest nadal nasycony. W tym miejscu pomaga również podejście oparte na inżynierii niezawodności baz danych (database reliability engineering), ponieważ łączy ono zachowanie zapytań z powtarzalnymi kontrolami operacyjnymi i zapobiega traktowaniu regresji związanych z pamięcią jako jednorazowych niespodzianek. Zobacz database reliability engineering practices, aby zapoznać się z szerszym modelem operacyjnym stojącym za tego rodzaju pracą.

Wdrażanie ciągłego monitorowania z Observability wewnątrz bazy danych

Jednorazowe dostrajanie jest przydatne, ale nie zapobiega kolejnej regresji. Dane rosną, rozkłady się zmieniają, obciążenia dryfują, a plan, który działał w zeszłym kwartale, może zestarzeć się bez ostrzeżenia. Dlatego ciągłe monitorowanie to jedyny rozsądny sposób, aby zapobiec sytuacji, w której wydajność zapytań staje się powracającym pożarem do ugaszenia.

Obserwuj odchylenia, zanim zrobią to użytkownicy

Użyteczna zmiana polega na przejściu od reakcji do wykrywania. Platformy in-database observability mogą monitorować metryki wydajności zapytań, zmiany wzorców wykonywania i sygnały terminowości bez przenoszenia danych poza środowisko, co ma znaczenie, gdy przepisy bezpieczeństwa lub zasady governance sprawiają, że przenoszenie danych jest kosztowne lub niepożądane. Narzędzie Data Platform Observability firmy digna jest jednym z przykładów takiego modelu, z monitorowaniem, które pozostaje wewnątrz środowiska klienta i śledzi stan obciążenia pracą, wzorce konsumpcji oraz metryki związane z wydajnością w całym środowisku danych (digna data observability).

Tego rodzaju monitorowanie oparte na punktach odniesienia (baselines) jest cenne, ponieważ wykrywa nietypowe zachowania, zanim pulpit nawigacyjny ulegnie awarii lub zostanie naruszone SLA. Celem nie jest zastąpienie dostrajania. Chodzi o to, aby dostrajanie miało charakter proaktywny, a nie reaktywny.

Użyj observability, aby zamknąć pętlę

Ciągłe monitorowanie sprawia, że wcześniejszy diagnostyczny przepływ pracy staje się trwałą praktyką. Zamiast jednorazowego diagnozowania spowolnienia i zapominania o nim, zespoły mogą porównywać nowe zachowanie ze starym planem, wcześnie wychwytywać regresje i utrzymywać obciążenie pracą blisko punktu odniesienia, który sprawdził się na produkcji. digna publikuje również przewodnik po SQL query optimisation, który wpisuje się w ten schemat, koncentrując się na rzeczywistych parametrach, planach wykonania, węzłach będących wąskimi gardłami, odświeżaniu statystyk i porównywaniu planów.

To jest część, którą bardzo cenię z punktu widzenia operacyjnego. Poprawki na poziomie zapytań są realne, ale tracą na sile, jeśli nikt nie monitoruje obciążenia po wdrożeniu zmiany. Observability zamienia to w rutynę, a nie w misję ratunkową.

Jeśli borykasz się z wolno działającą procedurą składowaną, planem, który stale się zmienia, lub zapytaniem, które wydawało się naprawione, dopóki dane ponownie się nie zmieniły, odwiedź digna i oceń, czy in-database observability może zapewnić Ci punkt odniesienia, wykrywanie anomalii i monitorowanie obciążenia pracą, których potrzebujesz do utrzymania stabilnej wydajności. Właściwy proces dostrajania nie kończy się na przepisaniu kodu – polega na ciągłym obserwowaniu systemu, aby kolejna regresja nie zaskoczyła Twojego zespołu.