Przejdź do treści
Programowanie

Analiza slow query log w MySQL: jak znajdować i naprawiać wolne zapytania

15 lipca 2026 7 min czytania

Aplikacja webowa spowalnia, ale nie wiadomo gdzie. CPU serwera jest niskie, RAM jest, ale strony ładują się wolno. Pierwsza rzecz do sprawdzenia to slow query log MySQL - lista zapytań, które trwają dłużej niż zadany próg.

Włączenie slow query log

W konfiguracji MySQL (my.cnf lub my.ini) ustaw trzy parametry: slow_query_log = 1, slow_query_log_file ze ścieżką do pliku logów i long_query_time z progiem w sekundach, np. 1. Po restarcie MySQL (lub przez SET GLOBAL bez restartu) baza zaczyna logować wolne zapytania.

Analiza wyników

Plik slow query log zawiera dla każdego zapytania: czas wykonania, czas blokady, liczbę przeskanowanych i zwróconych wierszy oraz treść zapytania. Narzędzie mysqldumpslow agreguje podobne zapytania i sortuje po łącznym czasie wykonania, co pozwala zidentyfikować najbardziej kosztowne wzorce zapytań.

EXPLAIN - plan wykonania

Gdy znasz wolne zapytanie, uruchom przed nim EXPLAIN. Wynik pokazuje jak MySQL planuje je wykonać: czy korzysta z indeksu, ile wierszy musi przeskanować, jaki typ joina użyje. Kolumna type powinna pokazywać ref lub eq_ref dla zapytań po kluczach. Wartość ALL oznacza pełne skanowanie tabeli - zazwyczaj problem do naprawienia przez dodanie indeksu.

Dodawanie indeksów

Indeks to osobna struktura danych, która przyspiesza wyszukiwanie po danej kolumnie lub kombinacji kolumn kosztem miejsca na dysku i czasu przy operacjach zapisu. Dla zapytań filtrujących po kolumnie (WHERE status = 'active') lub sortujących po kolumnie (ORDER BY created_at DESC), indeks na tej kolumnie drastycznie skraca czas wykonania.

Kiedy indeks nie pomaga

Indeks na kolumnie o małej liczbie unikalnych wartości (np. kolumna z dwoma wartościami: tak/nie) przynosi mało korzyści - MySQL może zdecydować że skanowanie pełnej tabeli jest szybsze. Zbyt wiele indeksów spowalnia operacje INSERT, UPDATE i DELETE. Indeksy są narzędziem do odpowiedzialnego stosowania, nie panaceum.

Query Cache kontra optymalizacja zapytań

MySQL Query Cache był rozwiązaniem dostępnym w starszych wersjach, które buforowało wyniki zapytań. Zostało usunięte w MySQL 8.0 jako zbyt obciążające przy współbieżnym pisaniu. Redis lub Memcached na poziomie aplikacji są lepszym rozwiązaniem dla buforowania wyników kosztownych zapytań, które często się powtarzają.