Przejdź do treści 
Wyjaśnię to Optymalizator MariaDB z praktyki: jak tworzy plany, szacuje koszty i dlaczego czasami się myli. Jak skutecznie analizować plan wykonania SQL, sensownie stosować indeksy i kierować optymalizatorem w oparciu o fakty, a nie przeczucia.
Punkty centralne
Na początek pokrótce podsumuję najważniejsze elementy, abyś mógł właściwie zorientować się w kolejnych sekcjach i Przegląd zachowujesz.
- Fazy: Analiza, przygotowanie, optymalizacja i wykonanie stanowią cykl życia każdego zapytania.
- Model kosztów: Wartości czasowe w mikrosekundach określają wybór indeksów, skanowanie oraz kolejność połączeń.
- Statystyki: Kardynalność i histogramy mają wpływ na oszacowanie selektywności.
- Przejrzystość: Polecenia EXPLAIN, EXPLAIN ANALYZE oraz Optimizer Trace pozwalają zajrzeć do „czarnej skrzynki”.
- Strojenie: Indeksy, przepisywanie zapytań, polecenie ANALYZE TABLE oraz parametry kosztowe zwiększają szybkość działania.
Cykl życia zapytania w MariaDB
Zanim powstanie plan, zapytanie przechodzi przez cztery etapy, które na co dzień celowo sprawdzam, aby Przyczyny wykrywania spowolnień. Podczas analizy składniowej MariaDB przekształca SQL w strukturę wewnętrzną; na tym etapie wykrywane są błędy składniowe. W fazie przygotowawczej silnik sprawdza tabele, kolumny i potencjalne indeksy oraz przeprowadza proste przekształcenia. Następnie następuje optymalizacja, podczas której obliczane są potencjalne plany i oceniane za pomocą modelu kosztów. Podczas wykonywania serwer realizuje wybrany plan krok po kroku: odczyt, połączenie, filtrowanie, zwracanie wyników.
Wyraźnie rozróżniam błędy analityczne według fazy, ponieważ dzięki temu diagnozy przynoszą szybsze efekty i Środki działać w sposób ukierunkowany. Problemy z wydajnością wynikają zazwyczaj z optymalizacji: błędnych oszacowań, brakujących indeksów lub niekorzystnej kolejności połączeń. Błędy parsowania są trywialne, ale faza przygotowania może już zawierać pewne sztuczki, takie jak rozdzielanie widoków czy przekształcanie podzapytań. Na etapie wykonania nieefektywność staje się bezlitośnie widoczna, jeśli wcześniej wybrano pełne skanowanie. Dlatego każdą analizę rozpoczynam od ustrukturyzowanego przeglądu wszystkich czterech etapów.
Jak optymalizator podejmuje decyzje wewnętrznie
MariaDB działa w oparciu o koszty i ocenia alternatywne warianty za pomocą Funkcja kosztu. Dla każdego wariantu serwer szacuje liczbę odczytanych wierszy, selektywność warunków WHERE/ON, rodzaje dostępu, takie jak skanowanie tabeli, skanowanie indeksu, skanowanie zakresu, a także czas wykonania poszczególnych operacji. Wewnętrznie serwer rozróżnia fazy join_preparation i join_optimization. W fazie join_preparation odbywa się przepisywanie zapytań, upraszczanie warunków, przekształcanie podzapytań oraz rozdzielanie widoków. W fazie `join_optimization` obliczane są kolejności połączeń, sprawdzane są indeksy kandydujące za pomocą `ref_optimizer_key_uses`, szacowana jest liczba wierszy za pomocą skanowania zakresu oraz warunki są przypisywane do konkretnych tabel tak wcześnie, jak to możliwe.
Ten mechanizm wyjaśnia, dlaczego mały filtr umieszczony w niewłaściwym miejscu powoduje kosztowne Konsekwencje ma. Jeśli operacja `attaching_conditions_to_tables` odbywa się zbyt późno, plan przetwarza niepotrzebnie zbyt wiele wierszy w ramach połączeń (joins). Jeśli statystyki są nieaktualne, wartości `rows_estimation` i `Selectivity` są błędne; optymalizator wybiera wówczas korzystne, ale w rzeczywistości powolne ścieżki dostępu. Właśnie na tych elementach skupiam się: lepsze statystyki, jaśniejsze predykaty, starannie posortowane indeksy złożone. Po tych zmianach wybór planu często ulega zauważalnej zmianie.
Model opłat od wersji MariaDB 11.0
Najnowsze wersje nie oceniają już pracy w przybliżeniu na podstawie wag, lecz za pomocą mikrosekundy dla konkretnych operacji związanych z pamięcią masową. Parametry takie jak `optimizer_disk_read_cost`, `optimizer_disk_read_ratio` i `optimizer_where_cost` sprawiają, że model jest bliższy rzeczywistym czasom wykonania. W ten sposób optymalizator porównuje skanowanie zakresu indeksu z pełnym skanowaniem w oparciu o rzeczywiste założenia czasowe. LAST_QUERY_COST pokazuje szacunkowy całkowity koszt i często znacznie lepiej koreluje z rzeczywistością niż wcześniej. W przypadku systemów przetwarzających duże ilości danych ta bardziej szczegółowa siatka natychmiast przynosi korzyści.
Dokładnie kalibruję model, gdy właściwości sprzętu są sprzeczne z domyślnymi założeniami, a tym samym Wybór planu zniekształcać. Dyski SSD NVMe, pamięci rozproszone lub specjalne pamięci podręczne mogą znacząco wpłynąć na współczynnik wykorzystania dysku i czasy odczytu. Niewielkie zmiany wartości parametrów `optimizer_costs` sprawiają, że MariaDB wybiera optymalne ścieżki. Dokumentuję każdą zmianę, a następnie sprawdzam EXPLAIN ANALYZE, aby zmierzyć jej wpływ. Bez pomiarów optymalizacja pozostaje loterią.
Selektywność, statystyki i histogramy
Dobre szacunki zaczynają się od dokładnych kardynalność oraz niezawodnej selektywności. MariaDB prowadzi statystyki dotyczące różnych wartości dla każdej kolumny i może opcjonalnie korzystać z histogramów rozkładów. Szczególnie dane o nierównomiernym rozkładzie – punkty o dużej częstotliwości, rozkłady Zipfa, wzorce sezonowe – czerpią korzyści z histogramów. Po wprowadzeniu znacznych zmian w danych wykonuję polecenie ANALYZE TABLE, aby optymalizacja znów opierała się na aktualnych danych. Kto o tym zapomni, ryzykuje pełne skanowanie, które jest obiektywnie błędne.
Planuję uruchamianie ANALYZE jako regularnego zadania, dostosowanego do Zmiany w zakresie objętości danych i w odniesieniu do tabel krytycznych. W przypadku silnie zniekształconych rozkładów kolumn histogramy pomagają realistycznie oszacować selektywność wartości wyjątkowych. Zmniejsza to ryzyko błędnych ocen w przypadku skanowania przedziałów i strategii scalania. W połączeniu z odpowiednimi indeksami złożonymi znacznie poprawia się dokładność trafień. Rezultat: krótszy czas działania i mniejsza liczba operacji wejścia/wyjścia.
EXPLAIN i odczytywanie planów wykonania
Aby uwidocznić procesy decyzyjne, używam poleceń EXPLAIN, EXPLAIN EXTENDED oraz FORMAT=JSON. Klasyczne kolumny zapewniają szybki przegląd: id, select_type, table, type, possible_keys, key, key_len, ref, rows oraz, w razie potrzeby, filtered. Wartość type=ALL wskazuje na pełne skanowanie, które rzadko jest pożądane. FORMAT=JSON pokazuje szczegółowo, w jaki sposób przesunięto warunki oraz jakie ścieżki ocenił optymalizator. W kontekście hostingu polecam przewodnik dotyczący Plany wykonawcze w ramach hostingu, aby powiązać informacje dotyczące planu z efektami infrastrukturalnymi.
W szybkiej interpretacji pomaga mi mała tabela, która w zwięzły sposób przedstawia typowe wartości, a tym samym Błędne interpretacje zapobiega.
| Pole EXPLAIN | Wartość typowa | Znaczenie w praktyce |
|---|---|---|
| typ | ALL, range, ref, eq_ref, const | Im dalej w prawo, tym bardziej selektywne; ALL oznacza skanowanie pełne. |
| possible_keys | Lista indeksów | Indeksy, które teoretycznie pasują; jeśli brakuje tu kandydatów, brakuje struktury. |
| Klucz | Nazwa indeksu | Rzeczywiście używany indeks; puste pole oznacza rezygnację z indeksu. |
| wiersze | Liczba | Szacowana liczba przeczytanych wierszy; znaczne odchylenie od rzeczywistości = błędne statystyki. |
| przefiltrowane | procent | Ile jest przekazywane dalej po filtru; często lepiej, gdy jest to niewielka ilość. |
Dlaczego optymalizator czasami się myli
Żaden model kosztów nie pasuje do każdej sytuacji, dlatego wprowadzam poprawki Błędy celowo. Nieaktualne statystyki prowadzą do błędnych oszacowań wierszy i niekorzystnej kolejności połączeń. Nieprawidłowo skonstruowane indeksy złożone uniemożliwiają wykorzystanie indeksów w przypadku filtrów wielokolumnowych. Bardzo zagnieżdżone podzapytania utrudniają skuteczne przepisywanie i blokują materializację. Brakujące lub mylące filtry zmuszają silnik do przesuwania wielu wierszy, zanim zastosowanie znajdą użyteczne predykaty.
Najpierw sprawdzam, czy sformułowanie zapytania jest zgodne z Indeks co naprawdę się sprawdza: reguła prefiksu po lewej stronie, odpowiednia kolejność sortowania, unikanie funkcji na kolumnach w klauzuli WHERE. Następnie sprawdzam w EXPLAIN ANALYZE, czy rzeczywistość potwierdza te szacunki. Jeśli nie, stosuję ANALYZE TABLE, a w razie potrzeby przepisuję zapytanie. Dopiero na samym końcu sięgam po FORCE INDEX lub hinting, ponieważ może to ograniczyć przyszłe optymalizacje.
Celowe wykorzystanie funkcji Optimizer Trace
Jeśli polecenie EXPLAIN nie wystarczy, włączam śledzenie optymalizatora i obserwuję Decyzje w dzienniku JSON. Widzę tam, które plany zostały rozważone, odrzucone lub zaakceptowane. Rozumiem, dlaczego jakiś warunek zadziałał z opóźnieniem lub dlaczego dany indeks nie znalazł się w wąskim gronie kandydatów. Dziennik pokazuje również, w jaki sposób zmieniono kolejność warunków. Ten wgląd pogłębia zrozumienie i dostarcza konkretnych punktów zaczepienia do kolejnego etapu optymalizacji.
Zapisuję istotne fragmenty śladu wraz z skrótem zapytania oraz Parametryoceniać. Dzięki temu będę mógł później porównać, która zmiana przyniosła jaki efekt. Dokumentacja serwera MariaDB oraz różne prezentacje w ramach ekosystemu zawierają szczegółowy opis tych pól (źródło: dokumentacja serwera MariaDB dotycząca optymalizatora zapytań i śladu optymalizatora). Dzięki temu narzędziu szybciej wykrywam błędne założenia niż metodą prób i błędów. Oszczędzam czas przede wszystkim w przypadku złożonych połączeń (join).
W praktyce: Optymalizacja bazy danych krok po kroku
Każdą optymalizację rozpoczynam od jasnego Pomiar. Problemy wykrywam za pomocą monitoringu oraz Wolny dziennik zapytań. Następnie porównuję EXPLAIN z EXPLAIN ANALYZE, aby zestawić plan z rzeczywistym wynikiem. Strategię indeksowania dostosowuję do warunków WHERE, JOIN i ORDER BY; indeksy złożone ukierunkowuję na najczęstsze punkty dostępu. FORCE INDEX stosuję tylko wtedy, gdy optymalizator wybiera niewłaściwy indeks pomimo poprawnych statystyk.
Każdy etap wymaga dbania o Statystyki: ANALYZE TABLE w przypadku tabel o dużej aktywności, histogramy dla rozkładów asymetrycznych. Upraszczam zbędne podzapytania, w razie potrzeby materializuję wyniki pośrednie i usuwam stare rozwiązania tymczasowe. W przypadku specjalistycznego sprzętu sprawdzam wartości optimizer_costs, aby model mikrosekundowy był poprawny. Każdą zmianę dokumentuję wartościami „przed” i „po”, aby jej wpływ pozostawał trwale weryfikowalny.
Typowe problemy związane z optymalizatorami i ich rozwiązania
Jeśli EXPLAIN typu ALL pokazuje, że pole „possible_keys” jest wypełnione, to najpierw sprawdzam Selektywność. Często kolejność kolumn w indeksie złożonym jest nieodpowiednia lub jakaś funkcja uniemożliwia wykorzystanie indeksu. W takim przypadku odwracam kolejność, usuwam przeszkadzające funkcje lub dzielę predykaty. W przypadku nieprawidłowej kolejności połączeń sprawdzam, czy możliwe jest wcześniejsze filtrowanie, na przykład poprzez umieszczenie bardziej selektywnej tabeli na początku. Podzapytania przekształcam, tam gdzie ma to sens, w połączenia lub tabele tymczasowe (TEMPORARY).
Błędne decyzje rozpoznaję również po znacznych odchyleniach wiersze między planem a rzeczywistością. W takim przypadku pomocne może być polecenie ANALYZE TABLE lub histogram dla danej kolumny. Jeśli nawet poprawne statystyki nie prowadzą do celu, rozważam zastosowanie wyraźnych wskazówek. Wcześniej zabezpieczam wyniki kontroli krzyżowej i wartości pomiarowe, aby późniejsze wersje optymalizatora nie były hamowane przez zapisane dane. W tym przypadku opłaca się dyscyplina w dokumentacji.
Kontekst hostingu i aspekty operacyjne
Jakość zapytań i infrastruktura muszą być do siebie dopasowane, w przeciwnym razie aplikacja nie wykorzysta w pełni swojego potencjału Potencjał. Szybkie dyski SSD, spójne pamięci podręczne i przejrzysta konfiguracja stanowią podstawę, na której optymalizator podejmuje trafne decyzje. Duży ruch nie pozwala na przeprowadzanie pełnych skanowań; nawet kilka nieefektywnych zapytań spowalnia całe systemy. W przypadku środowisk MySQL/MariaDB w środowisku produkcyjnym przydatne wskazówki praktyczne, takie jak Optymalizator MySQL przydatne wskazówki dotyczące połączenia planu i platformy. Kto bierze pod uwagę ten aspekt, zapobiega powstawaniu wąskich gardeł, zanim osiągną one poważny poziom.
Analizę planu zawsze łączę z wskaźnikami dotyczącymi I/O, opóźnienia i współbieżność. Jeśli wartości nie odpowiadają przyjętemu modelowi kosztów, sprawdzam parametry. Następnie analizuję rozmiary buforów, obciążenia równoległe oraz rozkład najczęściej wyszukiwanych zestawów. Dzięki takiemu podejściu udaje się zapewnić harmonijne działanie zapytań i zasobów oraz utrzymać szczytowe obciążenia pod kontrolą.
Ścieżki połączeń i dostępu w praktyce
Wiele nieporozumień wyjaśniam, przedstawiając Rodzaje dostępu dokładnie rozważam wszystkie za i przeciw. Jedno zakres- lub ref-Dostęp prawie zawsze się udaje WSZYSTKIE. W przypadku relacji równoważności opartych na kluczach unikalnych (eq_ref) są szczególnie stabilne. Sprawdzam też, czy jakiś Wskaźnik pokrycia który w pełni obsługuje zapytanie: jeśli w indeksie znajdują się wszystkie potrzebne kolumny, MariaDB oszczędza kosztowne operacje odczytu z tabeli. Index Condition Pushdown (ICP) pomaga w sprawdzaniu dodatkowych warunków WHERE już w indeksie – zmniejsza to liczbę zwracanych wierszy oraz operacji wejścia/wyjścia.
O Scalanie indeksów MariaDB może łączyć kilka indeksów (przekrój/zjednoczenie). Jest to przydatne w przypadku predykatów OR lub wielu warunków selekcyjnych, ale często działa wolniej niż dobrze dobrany indeks złożony. Ponadto oceniam MRR (odczyt wielozakresowy) oraz BKA (Batched Key Access). MRR sortuje klucze główne przeznaczone do odczytu, aby wyrównać losowe operacje we/wy; BKA grupuje operacje wyszukiwania w połączeniach (join) i przynosi korzyści zwłaszcza w przypadku połączeń bez pokrycia. W praktyce testuję BKA/MRR za pomocą optimizer_switch i sprawdzam za pomocą EXPLAIN ANALYZE, czy wzorce operacji wejścia/wyjścia ulegają zmniejszeniu. Jeśli natomiast MariaDB stosuje Blok pętli zagnieżdżonej (BNL), zazwyczaj bardziej opłaca się zwiększyć rozmiar bufora połączeń (join_buffer_size) – albo zastosować przepisanie kodu, które umożliwi wykonywanie prawdziwych połączeń indeksowych.
-- Przykład: indeks złożony dla operacji połączenia + filtrowania + sortowania
CREATE INDEX ix_orders_cust_status_created
ON orders (customer_id, status, created_at);
-- Typowy dostęp
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'open' AND o.created_at >= '2026-01-01'
ORDER BY o.created_at DESC
LIMIT 50;
Dzięki powyższemu indeksowi optymalizator może wybrać najbardziej selektywną kolejność, wcześnie przeprowadzić ocenę filtrów oraz często wykonać sortowanie bez konieczności stosowania dodatkowego sortowania plików.
ORDER BY, GROUP BY, sortowanie plików i tabele tymczasowe
Sortowanie i agregowanie zajmuje czas. Dbam o to, aby ORDER BY oraz GROUP BY mogą przebiegać zgodnie z kolejnością indeksów. Działa to wtedy, gdy prefiks i kierunek są dokładnie zgodne. W przeciwnym razie zastosowana zostanie Sortowanie plików z buforem sortowania (sort_buffer_size) i, w razie potrzeby, tabelą tymczasową. Jeśli zbiór wyników zawiera szerokie kolumny typu TEXT/BLOB, MariaDB działa szybciej na dysku Tabele TEMP (Aria). Zapobiegam temu, wybierając tylko niezbędne kolumny, ładując duże pola dopiero na końcu lub stosując prefiksy o ograniczonej długości.
W przypadku agregacji, o ile to możliwe, korzystam z, Skanowanie indeksu luźnego (np. GROUP BY na części indeksu wiodącej) i wybieram indeksy złożone wzdłuż grupowania. Gdy wyniki pośrednie stają się duże, materializacja z sensownymi kluczami skaluje się lepiej niż pojedyncze mega-łączenie. Regularnie mierzę wskaźniki handlerów oraz liczniki Created_tmp_*, aby wykrywać newralgiczne punkty związane z sortowaniem i tabelami tymczasowymi.
Podzapytania, półpołączenia i materializacja
Wiele podzapytań można efektywnie przekształcić na etapie przygotowania. Konstrukcje IN/EXISTS można traktować jako Semi-join działają, wykorzystując strategie takie jak materializacja czy LooseScan. Sprawdzam, czy optymalizator jest połączone_wynikowe można było wykonać: jeśli tabela pochodna (lub CTE z klauzulą WITH) zostanie wkomponowana do planu zewnętrznego, jej indeksy są bezpośrednio dostępne. Jeśli to się nie uda, podzapytanie trafia do tabeli tymczasowej – w takim przypadku, o ile to możliwe, nadaję jej klucz (np. za pomocą SELECT DISTINCT/ORDER BY na kolumnach kluczowych), aby połączenia na jej podstawie nie zakończyły się w nicości.
-- Przykład: EXISTS zamiast IN oraz tabela pochodna umożliwiająca scalanie
SELECT o.id
FROM orders o
WHERE EXISTS (
SELECT 1 FROM payments p
WHERE p.order_id = o.id AND p.state = 'captured'
);
-- Tabela pochodna z unikalnymi kluczami
WITH paid_orders AS (
SELECT DISTINCT order_id
FROM payments
WHERE state = 'captured'
)
SELECT o.*
FROM orders o
JOIN paid_orders po ON po.order_id = o.id;
Za pomocą polecenia EXPLAIN FORMAT=JSON sprawdzam, czy zrealizowane lub podzapytanie zależne został wybrany oraz czy obowiązują warunki (przesuwanie warunków) podjąć odpowiednio wcześnie.
Podział na partycje i przycinanie
Podział na partycje nie zastępuje indeksów, ale może Ilość danych na jedno wywołanie znacznie zmniejszyć. Optymalizator przeprowadza przycinanie poprawnie tylko wtedy, gdy predykat spełnia warunek Klucz partycji jest jednoznacznie określony i nie jest zamaskowany przez funkcje. Dlatego unikam wyrażeń takich jak DATE(created_at) w klauzuli WHERE w przypadku tabel partycjonowanych i zamiast tego korzystam z granic przedziałów. Polecenie EXPLAIN pokazuje, które partycje są odczytywane; szerokie przedziały wskazują na nieefektywne przycinanie.
Zbyt duża liczba małych partycji zwiększa nakłady związane z planowaniem. Dlatego wybieram sensowną szczegółowość (np. miesięczną zamiast dziennej), dbam o aktualność statystyk dla każdej partycji (ANALYZE PARTITION) oraz sprawdzam, czy ważne indeksy są dostępne lokalnie w partycjach. W przypadku projektów migracyjnych uwzględniam wpływ na replikację i tworzenie kopii zapasowych – oba te czynniki mają wpływ na to, jak intensywnie dokonuję partycjonowania.
Sargability i wzorce rewrite
Najprostsza metoda pozostaje Możliwość umieszczenia w trumnie – Warunki umożliwiające wykorzystanie indeksów. Unikam funkcji na kolumnach w klauzuli WHERE, zwracam stałe po stronie kolumn i w razie potrzeby rozdzielam warunki OR na UNIA WSZYSTKO. W przypadku wyszukiwania typu LIKE bez początkowego kotwicy ("%foo") indeks BTREE się nie sprawdza; w tym przypadku planuję zastosować wyszukiwanie pełnotekstowe lub odpowiednią usługę wyszukiwania. Do obliczeń używam kolumny generowane z indeksami, aby optymalizator mógł odtworzyć logikę zawartą w indeksie.
-- Antywzorzec: funkcja na kolumnie
WHERE DATE(created_at) = '2026-08-01'
-- Lepiej: zakres na wartości surowej
WHERE created_at >= '2026-08-01' AND created_at < '2026-08-02'
-- Antywzorzec: operator OR uniemożliwia korzystanie z indeksu
WHERE status = 'open' OR customer_id = 42
-- Lepsze rozwiązanie: dwa zapytania z UNION ALL, z których każde ma własny indeks
(SELECT ... WHERE status = 'open')
UNION ALL
(SELECT ... WHERE customer_id = 42');
Jeśli chodzi o indeksy złożone, uważam, że zasada lewego przedrostka Ściśle przestrzegaj zasad, sortuj kolumny według selektywności oraz według kolejności, w jakiej będą później potrzebne do sortowania. Jeśli potrzebuję sortowania malejącego (ORDER BY), uwzględniam to w układzie indeksu – w ten sposób oszczędzam sobie sortowania plików.
Przełącznik optymalizatora i precyzyjna regulacja kosztów
Zanim zacznę przeglądać zapytania, sprawdzam optimizer_switch oraz bufory pamięci. Funkcje takie jak mrr, batched_key_access, index_merge, semijoin, połączone_wynikowe lub warunek_pushdown_dla_typów_pochodnych można dostosować dla każdej sesji. Aktywuję kandydatów celowo na potrzeby sesji testowej, dokonuję pomiaru za pomocą EXPLAIN ANALYZE i cofam zmiany, jeśli efekt nie jest widoczny. Ścieżka połączenia korzysta z wystarczającej join_buffer_size; różne rodzaje sort_buffer_size. Jednocześnie monitoruję bufory w kontekście współbieżności, aby serwer nie zaczął korzystać z pamięci wymiany pod wpływem obciążenia równoległego.
Jeśli chodzi o koszty, w razie potrzeby koryguję wspomniane już optimizer_costs w mikrosekundach. Moja zasada: małe, odwracalne kroki z udokumentowanymi punktami pomiarowymi. Korzystam z KOSZT_OSTATNIEGO_ZAPYTANIA w celu sprawdzenia poprawności oraz powtórz pomiary przy użyciu realistycznych wartości parametrów, ponieważ plany mogą w dużym stopniu zależeć od konkretnych wartości literałowych.
Stabilność planu, regresje i przepływ pracy w zespole
Nawet dobry plan może zostać zakłócony przez wzrost ilości danych lub zmianę wersji przewracać się. Dlatego gromadzę informacje o planach: skróty zapytań, dane JSON z EXPLAIN, fragmenty śladów optymalizatora oraz czasy wykonania EXPLAIN ANALYZE. Zmiany w indeksach i przepisywanie kodu realizuję w formie pull requestów wraz z dowodami stanu przed i po. W środowiskach CI/CD automatycznie sprawdzam krytyczne zapytania na reprezentatywnych zestawach danych. W ten sposób wykrywam Plany regresji wcześnie rano.
W trudnych przypadkach uważam, że Wskazówki (FORCE INDEX, STRAIGHT_JOIN, optimizer_switch na zapytanie) są dostępne jako ostateczna opcja, ale należy z nich korzystać oszczędnie i z terminem wygaśnięcia. Lepiej jest usunąć przyczyny – statystyki, indeksy, sformułowanie. W zespołach zwięzły przewodnik dotyczący skalowalności, projektowania indeksów i dyscypliny pomiarowej gwarantuje, że nowe funkcje nie spowodują niezauważalnego spadku wydajności.
Krótkie podsumowanie: Od planu do wyników
Kto może korzystać z Plan rozumie i kontroluje wydajność. Etapy analizy składniowej (Parsing), przygotowania (Preparing), optymalizacji (Optimizing) i wykonania (Executing) wyjaśniają, gdzie traci się czas. Model kosztów oparty na czasie, dostępny od wersji 11.0, wraz z aktualizowanymi statystykami i histogramami sprawia, że szacunki są wiarygodne. Funkcje EXPLAIN, EXPLAIN ANALYZE oraz ślad optymalizatora zapewniają przejrzystość, którą przekładam na konkretne działania. Dzięki przemyślanej strategii indeksowania, przejrzystemu projektowi zapytań i odpowiedniej infrastrukturze zapytania w MariaDB zapewniają niezmiennie szybkie odpowiedzi.
