Jak zrobić monitorowanie zapytań do bazy danych w WordPress

Wprowadzenie – Dlaczego monitorować zapytania do bazy

Wolna strona WordPress nie zawsze oznacza problem z bazą danych. Przyczyną mogą być też PHP, zewnętrzne API lub brak pamięci podręcznej. Monitorowanie zapytań pomaga sprawdzić, ile czasu zajmuje baza i który kod wysyła kosztowne lub powtarzające się zapytania.

Zacznij od problematycznego adresu i porównuj takie same żądania: na przykład stronę produktu przed zmianą i po niej. Liczy się łączny czas zapytań i ich kontekst, nie sama liczba.

Wbudowane narzędzia WordPress do monitorowania

Na kopii testowej możesz tymczasowo włączyć SAVEQUERIES. W pliku wp-config.php, przed załadowaniem WordPressa, dodaj poniższy wpis. Jeśli stała jest już zdefiniowana, zmień istniejący wpis zamiast dodawać kolejny:

define( 'SAVEQUERIES', true );

WordPress zapisuje zapytania obsługiwane przez $wpdb, ich czas i informacje o wywołaniu w tablicy $wpdb->queries dostępnej w kodzie podczas danego żądania. To nie jest trwały log ani monitoring całego serwera bazy danych. Dane mogą zawierać informacje wrażliwe: nie wyświetlaj ich publicznie i nie zapisuj bez kontroli dostępu.

Zbieranie danych zużywa zasoby. Po diagnozie usuń dodany wpis albo ustaw istniejącą stałą na false. Szczegóły opisuje dokumentacja WordPressa.

Użycie Query Monitor do analizy

Query Monitor pokazuje dane diagnostyczne bieżącego żądania, w tym zapytania wolne, powtarzające się i zakończone błędem. Pozwala filtrować je według funkcji i komponentu, na przykład wtyczki lub motywu.

1. Na stagingu zainstaluj i aktywuj Query Monitor z katalogu wtyczek WordPressa.
2. Zaloguj się jako administrator, otwórz problematyczną stronę i wybierz Query Monitor z paska administracyjnego.
3. W panelu zapytań sprawdź czas, powtórzenia i wywołujący komponent. Zapisz wyniki, wprowadź jedną zmianę i ponów pomiar w tych samych warunkach.

Domyślnie wyniki widzi administrator, a w multisite superadministrator; wtyczka umożliwia też dostęp przez specjalne ciasteczko diagnostyczne. Traktuj je jak dostęp do danych wrażliwych. Pomiar zalogowanego użytkownika może różnić się od wizyty gościa obsłużonej z cache. Po diagnozie wyłącz wtyczkę; jej działanie również wpływa na zużycie zasobów.

Analiza zapytań przez WP-CLI

WP-CLI nie przechwytuje automatycznie zapytań wykonywanych przez odwiedzających. Polecenie wp db query wykonuje podany SQL na bazie skonfigurowanej w wp-config.php. Przydaje się do analizy konkretnego zapytania, ale może też zmieniać dane — nie uruchamiaj nieznanego SQL.

Przykładowo na kopii testowej, w katalogu instalacji WordPressa, możesz obejrzeć plan prostego zapytania. Zastąp wp_posts rzeczywistą nazwą tabeli, jeśli używasz innego prefiksu:

wp db query "EXPLAIN SELECT ID FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish'"

To przykład diagnostyczny, nie test szybkości całej witryny. Unikaj wklejania do terminala zapytań z danymi klientów; historia poleceń i wyniki też mogą je ujawnić. Zobacz dokumentację wp db query.

Implementacja własnego systemu logowania

Własny logger ma sens, gdy potrzebujesz danych niedostępnych w istniejących narzędziach. Zacznij od metryk, takich jak liczba zapytań i ich łączny czas dla danego typu żądania, zamiast zapisywać pełne SQL. Ustal czas przechowywania, rotację, ograniczenie dostępu i sposób usuwania danych.

Pełne zapytania mogą zawierać dane osobowe lub inne sekrety. Nie zapisuj ich w publicznym katalogu ani w tej samej bazie bez oceny dodatkowego obciążenia. Przetestuj mechanizm na stagingu; dla stałego monitoringu rozważ gotowe APM lub diagnostykę serwera bazy uzgodnioną z administratorem.

Monitorowanie wolnych zapytań

Posortuj zapytania według czasu i sprawdź zarówno pojedyncze kosztowne zapytania, jak i wiele krótkich wywołań o dużym łącznym czasie. Zanotuj adres, rodzaj użytkownika, stan cache i liczbę wyników. Powtórz pomiar: pojedynczy wynik może zależeć od obciążenia serwera.

Dla wybranego zapytania SELECT przeanalizuj plan przez EXPLAIN: zwróć uwagę na użyty indeks i szacowaną liczbę analizowanych wierszy. Sprawdź, czy kod nie pobiera większej liczby danych, niż potrzebuje. Nie zakładaj z góry, że JOIN albo podzapytanie jest źródłem problemu — rozstrzygają plan i pomiary.

Analiza zapytań powtarzających się

W Query Monitor sprawdź grupę duplikatów i funkcje, które je wywołały. Jeśli kod pobiera te same dane w każdej iteracji pętli, często można pobrać je wcześniej i wykorzystać ponownie. Nie każde powtórzenie jest błędem: sprawdź jego łączny koszt i znaczenie dla strony.

Cache obiektów może ograniczyć ponowne pobieranie danych, a cache stron — generowanie całej strony dla kolejnych gości. Dobierz czas życia i unieważnianie do danych. W sklepie nie serwuj z publicznego cache koszyka, kasy ani danych konkretnego użytkownika.

Optymalizacja indeksów bazy danych

WordPress tworzy podstawowe indeksy, również dla meta_key w standardowych tabelach metadanych. Nie dodawaj ich ponownie w ciemno. Sprawdź istniejącą strukturę oraz plan konkretnego zapytania; kolejność kolumn indeksu złożonego ma znaczenie.

Nowy indeks zajmuje miejsce i zwiększa koszt zapisów, a jego tworzenie na dużej tabeli może obciążyć serwer. Najpierw przygotuj sprawdzoną kopię zapasową, przetestuj zmianę na reprezentatywnej kopii i zaplanuj wycofanie. Porównaj plan oraz czasy przed zmianą i po niej; operację produkcyjną uzgodnij z administratorem.

Automatyzacja alertów o problemach

Stały monitoring warto oprzeć na metrykach z APM lub serwera bazy danych. Ustal punkt odniesienia osobno dla stron publicznych, panelu i zadań w tle. Alert uruchamiaj przy utrzymującym się odchyleniu, a nie na podstawie uniwersalnej liczby zapytań.

Ogranicz częstotliwość powiadomień, wskaż osobę odpowiedzialną i sprawdź dostarczenie testowego alertu. Nie wysyłaj pełnego SQL ani danych klientów do kanałów powiadomień. Na hostingu współdzielonym konfigurację logu wolnych zapytań uzgodnij z dostawcą, bo może dotyczyć także innych witryn.

Podsumowanie – Wpływ na wydajność witryny

Zacznij od pomiaru problematycznej strony, znajdź najbardziej kosztowne zapytanie i jego źródło, a następnie sprawdź plan wykonania. Zmieniaj jedną rzecz naraz i porównuj wyniki w podobnych warunkach. Po zakończeniu wyłącz tymczasową diagnostykę i usuń niepotrzebne dane.

Jeśli chcesz dowiedzieć się więcej o kompleksowej optymalizacji WordPress, polecam nasz artykuł o optymalizacji MySQL/MariaDB dla WordPress, który zawiera dodatkowe wskazówki i najlepsze praktyki.