Baza WordPressa może mieć kilka megabajtów albo dziesiątki gigabajtów. Sam rozmiar nie mówi jednak, czy jest „zła”. Sklep z historią zamówień naturalnie przechowuje więcej danych niż strona wizytówkowa. Optymalizacja polega na znalezieniu niepotrzebnego lub źle używanego obciążenia: ogromnych logów, osieroconych tabel, nadmiernego autoloadu, brakujących indeksów albo zapytań pobierających za dużo danych.
Szybka odpowiedź
Zacznij od raportu rozmiarów tabel i slow query logu. Sprawdź wp_options, tabele sesji/logów oraz dane dodawane przez największe wtyczki. Dopiero potem decyduj o czyszczeniu. Przed każdą operacją kasującą wykonaj backup bazy i upewnij się, że potrafisz go odtworzyć.
Rewizje i kosz WordPressa
Rewizje wpisów i elementy w koszu mogą zajmować miejsce, ale rzadko są główną przyczyną wielosekundowych zapytań. Ograniczenie retencji może mieć sens w bardzo aktywnych redakcjach. Nie warto jednak usuwać historii zmian tylko po to, aby baza wyglądała „ładniej” w panelu wtyczki optymalizacyjnej.
Tabele logów i statystyk
Rozszerzenia bezpieczeństwa, statystyk, wyszukiwania i integracji potrafią zapisywać ogromne wolumeny danych. Sprawdź retencję. Jeżeli log techniczny ma wartość operacyjną tylko przez 30 dni, trzymanie go bez końca w tej samej bazie produkcyjnej może nie mieć sensu. Ustal jednak wymagania audytowe zanim cokolwiek usuniesz.
Indeksy ważniejsze niż odchudzanie
Tabela może mieć milion rekordów i działać dobrze, jeśli zapytania korzystają z odpowiednich indeksów. Z kolei mała tabela bez indeksu może wykonywać kosztowne skany. Slow query log i EXPLAIN pokazują realną pracę bazy. Dodawanie indeksów wymaga wiedzy o zapytaniach i wpływie na zapis, więc nie rób tego masowo z przypadkowego skryptu.
Osierocone dane po wtyczkach
Plugin może zostawić tabele po odinstalowaniu. Jeśli masz pewność, że rozszerzenie nie wróci i dane nie są potrzebne, można je usunąć. Najpierw wykonaj inwentaryzację oraz kopię. Nazwa tabeli zwykle podpowiada właściciela, ale nie zawsze — wiele systemów używa wspólnych struktur WordPressa zamiast własnych tabel.
OPTIMIZE TABLE nie jest magicznym przyspieszaczem
Operacje serwisowe mogą odzyskać miejsce w określonych sytuacjach, ale nie zastąpią poprawnego modelu danych i zapytań. Na dużej tabeli mogą również blokować lub intensywnie obciążać bazę. Planuj je w oknie serwisowym i zgodnie z typem silnika oraz wersją bazy.
Jak potwierdzić, że naprawa naprawdę działa?
Po każdej większej operacji porównaj rozmiary tabel, czas najwolniejszych zapytań i TTFB. Wykonaj test funkcjonalny zapisu: utwórz szkic, dodaj komentarz/testowe zamówienie lub inną operację właściwą dla serwisu. Optymalizacja nie może naruszyć możliwości zapisu. Jeśli usuwasz logi lub sesje, potwierdź również, że nowa polityka retencji zapobiega ponownemu niekontrolowanemu wzrostowi.
Co obserwować po zmianie?
Monitoruj tempo przyrostu bazy po tygodniu i miesiącu. Jednorazowe zmniejszenie tabeli z 10 GB do 2 GB nie rozwiązuje problemu, jeśli plugin co tydzień dopisuje kolejne 500 MB. Dobre utrzymanie obejmuje retencję, indeksy i obserwację zapytań, nie tylko okresowe „sprzątanie”.
Kiedy przekazać temat dalej?
Eskaluj przed ręcznym dodawaniem indeksów do dużych tabel produkcyjnych lub usuwaniem danych WooCommerce. Zmiana indeksu może być kosztowna i blokująca, a dane sklepu mają znaczenie księgowe i operacyjne. W takich przypadkach potrzebny jest plan i okno serwisowe.
Praktyczny scenariusz diagnostyczny
Załóżmy, że baza urosła do kilku gigabajtów, ale sama wielkość nie mówi, co jest problemem. Zrób zestawienie największych tabel, sprawdź tempo ich wzrostu i rodzaj danych. W WooCommerce duże tabele zamówień mogą być normalne, podczas gdy milion niepotrzebnych rekordów logów lub sesji już nie. Przed czyszczeniem wykonaj backup i ustal retencję: ile rewizji, transientów, logów i danych tymczasowych rzeczywiście potrzebujesz. Po operacji porównaj liczbę rekordów, rozmiar i konkretne wolne zapytania. Optymalizacja bazy nie powinna polegać na klikaniu „optimize all tables” bez diagnozy. Największy efekt często daje zatrzymanie źródła niekontrolowanego wzrostu, aby ten sam problem nie wrócił po kilku tygodniach.
Bezpieczna kolejność działań
- Zrób pełny backup bazy i test odtworzenia.
- Zbierz rozmiary tabel oraz slow query log.
- Sprawdź autoload, logi, transients i dane porzuconych wtyczek.
- Optymalizuj na podstawie zapytań, nie tylko rozmiaru.
- Kasowanie wykonuj etapami i po każdym etapie testuj aplikację.
- Porównaj czasy zapytań oraz TTFB po zmianach.
Czego nie robić
Nie uruchamiaj „clean all database” na produkcji bez listy tego, co zostanie usunięte. Nie traktuj najmniejszej możliwej bazy jako celu — celem jest szybka, przewidywalna i odtwarzalna aplikacja.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
HeatLogic może przygotować profil bazy, znaleźć największe tabele i wolne zapytania, a następnie wykonać kontrolowane czyszczenie i optymalizację z backupem i testem po każdej zmianie.
Najczęściej zadawane pytania
Czy duża baza zawsze spowalnia WordPressa?
Nie. Ważniejszy jest sposób zapytań, indeksy i dane ładowane przy każdym żądaniu.
Czy można usunąć wszystkie rewizje?
Technicznie można ograniczać lub czyścić rewizje, ale tracisz historię zmian. Najpierw oceń, czy oszczędność jest warta tej utraty.
Czy wtyczka do czyszczenia bazy jest bezpieczna?
Może być użyteczna, ale przed wykonaniem operacji trzeba wiedzieć, co dokładnie usunie i mieć sprawdzony backup.
Co najczęściej rośnie w bazie?
Zależy od serwisu: logi, sesje, dane analityczne, kolejki, transients, zamówienia i dane własnych wtyczek.