Wolny WordPress nie zawsze wymaga mocniejszego serwera. Często problemem są kosztowne zapytania do rozrastających się tabel, zwłaszcza wp_postmeta i wp_options. Indeksy bazy danych mogą skrócić wyszukiwanie rekordów, ale ich dodawanie powinno wynikać z pomiarów, a nie z przypuszczeń.
Dlaczego WordPress z czasem zwalnia?
WordPress przechowuje podstawowe dane wpisów w tabelach, a dodatkowe atrybuty zapisuje jako metadane. W tabeli wp_postmeta znajdują się między innymi wartości pól niestandardowych, ustawienia produktów WooCommerce i dane dodawane przez wtyczki. Przy dużej liczbie wpisów, produktów oraz rozszerzeń tabela może urosnąć do setek tysięcy lub milionów wierszy.
Indeks jest dodatkową strukturą, która pomaga bazie szybciej znaleźć rekordy spełniające warunek zapytania. Bez użytecznego indeksu MySQL lub MariaDB może wykonać full table scan, czyli przejść po całej tabeli i sprawdzić każdy wiersz. Na małej stronie różnica bywa niezauważalna. W dużym sklepie takie zapytania mogą jednak tworzyć wyraźne opóźnienia.
Domyślne indeksy WordPressa nie zawsze odpowiadają zapytaniom generowanym przez motyw, wtyczki lub WooCommerce. Nie oznacza to jednak, że należy indeksować każdą kolumnę. Każdy indeks przyspiesza wybrane odczyty, ale zwiększa miejsce zajmowane przez bazę i wymaga aktualizacji podczas operacji INSERT, UPDATE oraz DELETE.
Jak sprawdzić, czy potrzebujesz indeksu?
Najpierw znajdź konkretne wolne zapytanie. Dodanie indeksu bez wiedzy o tym, które zapytanie powoduje problem, jest zgadywaniem i może pogorszyć wydajność zapisu.
Do diagnostyki wykorzystaj następujące narzędzia:
- Query Monitor – pokazuje zapytania wykonywane podczas ładowania strony, ich czas oraz miejsce wywołania, na przykład konkretną wtyczkę.
- EXPLAIN w phpMyAdmin – pozwala sprawdzić plan wykonania zapytania, użyty indeks oraz liczbę analizowanych wierszy.
- Slow Query Log – loguje zapytania przekraczające ustalony czas wykonania i pomaga wykryć problemy występujące poza pojedynczym żądaniem.
- Statystyki tabeli – rozmiar i liczba wierszy pomagają ocenić, czy koszt pełnego skanowania może być istotny.
Skopiuj podejrzane zapytanie z Query Monitor i przeanalizuj je poleceniem EXPLAIN. Zwróć uwagę na plan wykonania oraz na to, czy baza korzysta z indeksu. Sam fakt, że indeks istnieje, nie oznacza jeszcze, że optymalizator go wybierze. Przy małej tabeli pełne skanowanie może być tańsze niż odczyt indeksu.
Jak bezpiecznie dodać indeks do WordPressa?
Przed każdą zmianą struktury bazy wykonaj pełny backup i sprawdź, czy można go odtworzyć. Operacja na dużej tabeli może potrwać, obciążyć serwer lub zakończyć się problemem wynikającym z ograniczeń silnika bazy. Zmiany testuj najpierw na kopii stagingowej, jeśli masz taką możliwość.
- Zmierz problem w Query Monitor i zapisz konkretne zapytanie, które działa zbyt wolno.
- Uruchom
EXPLAINdla tego zapytania w phpMyAdmin lub konsoli MySQL/MariaDB. Sprawdź, po której kolumnie odbywa się filtrowanie. - Zweryfikuj istniejące indeksy, aby nie tworzyć duplikatu. W phpMyAdmin możesz wyświetlić strukturę tabeli, a w SQL użyć polecenia
SHOW INDEX FROM wp_postmeta. - Wykonaj zmianę po przygotowaniu backupu, przykładowo dla kolumny
meta_key:ALTER TABLE wp_postmeta ADD INDEX idx_postmeta_meta_key (meta_key); - Uruchom ponownie analizowane zapytanie i porównaj plan wykonania oraz czas działania przed i po zmianie.
- Obserwuj stronę po wdrożeniu. Sprawdź nie tylko odczyty, ale także zapisy metadanych, importy produktów i działanie zadań cron.
Podany przykład jest punktem wyjścia, a nie uniwersalną receptą. W niektórych instalacjach lepszy będzie indeks złożony, na przykład obejmujący meta_key oraz inną kolumnę używaną w filtrze. Kolejność kolumn ma znaczenie, dlatego projekt indeksu trzeba dopasować do rzeczywistego zapytania.
Nie indeksuj bezrefleksyjnie kolumny meta_value. W tabeli wp_postmeta przechowuje ona różne typy danych, a jej indeksowanie może wymagać prefiksu i nie zawsze rozwiązuje problem. Kolumny tekstowe typu TEXT lub BLOB mają dodatkowe ograniczenia. Przy WooCommerce problem może dotyczyć również tabel zamówień, produktów lub logów, więc analizuj konkretne zapytanie zamiast stosować tę samą zmianę wszędzie.
Kiedy indeks pomaga, a kiedy lepiej go nie dodawać?
Decyzja zależy głównie od rozmiaru tabeli, częstotliwości odczytów, selektywności kolumny i liczby operacji zapisu.
| Sytuacja | Rekomendacja | Uzasadnienie |
|---|---|---|
Częste filtrowanie dużej tabeli po meta_key |
Rozważyć indeksowanie | Indeks może ograniczyć liczbę sprawdzanych wierszy w wp_postmeta. |
| Mała tabela z kilkudziesięcioma wierszami | Nie dodawać automatycznie | Pełne skanowanie może być prostsze i wystarczająco szybkie. |
| Kolumna z jedną wartością dla niemal wszystkich rekordów | Zwykle nie indeksować | Niska selektywność ogranicza korzyść z indeksu. |
| Kolumna często zmieniana podczas importów lub aktualizacji | Wdrożyć tylko po pomiarach | Każdy zapis musi również aktualizować indeks. |
| Zapytania filtrujące po kilku kolumnach | Rozważyć indeks złożony | Odpowiednia kolejność kolumn może lepiej odpowiadać warunkom WHERE. |
Czego unikać przy optymalizacji indeksów?
Najczęstszy błąd polega na dodawaniu indeksów „na wszelki wypadek”. Taka strategia zwiększa rozmiar bazy i może spowolnić importy, zapisy produktów oraz aktualizację metadanych.
Przy pracy z indeksami nie rób następujących rzeczy:
- Nie modyfikuj bazy produkcyjnej bez aktualnej kopii zapasowej.
- Nie twórz kilku podobnych indeksów bez sprawdzenia istniejącej struktury tabeli.
- Nie zakładaj, że każda kolumna używana w
WHEREautomatycznie potrzebuje indeksu. - Nie oceniaj efektu wyłącznie po czasie ładowania jednej strony, pomijając zapisy, importy i zadania cron.
- Nie usuwaj indeksu systemowego lub dodanego przez wtyczkę bez sprawdzenia, jakie zapytania go wykorzystują.
Czy warto użyć wtyczki do indeksowania?
Wtyczki takie jak Index WP MySQL For Speed mogą ułatwić analizę i wdrażanie zmian, szczególnie osobom, które nie pracują na co dzień z SQL. Nadal trzeba jednak sprawdzić, jakie indeksy zostaną dodane, do których tabel i z jakiego powodu. Automatyzacja nie zastępuje pomiaru.
Przy dużej bazie WooCommerce, niestandardowych tabelach lub problemach po zmianie indeksów lepiej wykonać operację na stagingu albo skonsultować ją z administratorem baz danych. Jeśli po wdrożeniu strona traci dostępność, zapytania blokują tabelę albo baza ma rozmiar liczony w gigabajtach, potrzebna może być analiza planów zapytań, obciążenia zapisu i konfiguracji InnoDB, a nie tylko kolejny indeks.
Najbezpieczniejszy schemat to: backup, pomiar w Query Monitor, analiza przez EXPLAIN, jedna zmiana, ponowny pomiar i obserwacja zapisów. Indeks ma sens wtedy, gdy rozwiązuje konkretny problem i jego zysk przewyższa koszt utrzymania.
