Baza WordPress zajmuje za dużo miejsca — co sprawdzić? | TopHostings.pl

Duża baza WordPressa nie oznacza automatycznie problemu. Sklep z tysiącami zamówień, rozbudowany serwis albo witryna zapisująca dużo danych przez wtyczki może potrzebować znacznie więcej miejsca niż prosta strona firmowa.

Niepokojący jest przede wszystkim wzrost, którego nie potrafisz wyjaśnić: baza przybywa o setki megabajtów w krótkim czasie, jedna tabela zaczyna dominować nad pozostałymi albo hosting sygnalizuje zbliżanie się do limitu.

Nie zaczynaj od „optymalizowania całej bazy”. Najpierw sprawdź, które tabele rosną i jakie dane rzeczywiście zawierają.

Najpierw sprawdź, które tabele zajmują miejsce

Rozmiar całej bazy jest tylko punktem wyjścia. Do diagnozy potrzebujesz rozbicia na poszczególne tabele.

W typowej instalacji WordPressa znajdziesz między innymi tabele związane z:

wpisami i stronami,
metadanymi treści,
użytkownikami,
komentarzami,
ustawieniami,
taksonomiami.

Wtyczki mogą dodawać własne tabele albo zapisywać dane w istniejących strukturach WordPressa. Dlatego sama nazwa tabeli często daje pierwszy trop, ale nie zawsze wystarcza do podjęcia decyzji o usunięciu danych.

Co widzisz	Co sprawdzić
Jedna tabela jest znacznie większa od pozostałych	Jaki komponent ją utworzył i jakie rekordy przechowuje
Duże `wp_postmeta`	Liczbę rekordów, źródło metadanych, osierocone dane
Duże `wp_options`	Rozmiar rekordów i dane ładowane automatycznie
Duże tabele pluginu	Logi, kolejki, statystyki, cache, historia zdarzeń
Baza rośnie mimo małej liczby nowych treści	Automatyczne logowanie lub proces zapisujący dane w tle

Duże wp_postmeta nie musi oznaczać uszkodzonej bazy

Tabela metadanych wpisów może rosnąć znacznie szybciej niż liczba samych wpisów. Jeden produkt WooCommerce, formularz albo typ treści może mieć dziesiątki powiązanych rekordów metadata.

Problem pojawia się wtedy, gdy liczba rekordów rośnie bez proporcjonalnego wzrostu użytecznych danych albo w tabeli pozostają rekordy związane z obiektami, które już nie istnieją.

Nie należy usuwać wpisów z wp_postmeta tylko dlatego, że tabela jest duża. Część danych może być potrzebna wtyczkom, motywowi lub samemu WordPressowi.

Bezpieczna diagnostyka powinna odpowiedzieć przynajmniej na trzy pytania:

które klucze meta_key występują najczęściej,
który komponent je tworzy,
czy odpowiadają istniejącym obiektom.

wp_options może być niewielka, a mimo to wpływać na działanie strony

W wp_options znajdują się ustawienia WordPressa i wtyczek. Część opcji WordPress ładuje automatycznie przy wielu żądaniach. W aktualnych wersjach WordPressa mechanizm autoload ma kilka możliwych stanów i nie należy diagnozować go wyłącznie przez stare założenie autoload = yes.

Dlatego przy tej tabeli liczy się nie tylko całkowity rozmiar, ale również struktura danych i sposób ich ładowania. Site Health może też ostrzegać o nadmiernej ilości danych ładowanych automatycznie.

Duży pojedynczy rekord, rozbudowany cache zapisany jako option albo pozostawione ustawienia starej wtyczki mogą zwiększać ilość danych przetwarzanych przez aplikację. Nie oznacza to jednak, że każdą dużą wartość można bezpiecznie usunąć.

WordPress udostępnia API Options właśnie po to, aby komponenty przechowywały i odczytywały ustawienia według określonego kontraktu. Ręczne kasowanie rekordów bez ustalenia ich właściciela może uszkodzić konfigurację witryny.

Logi, kolejki i statystyki potrafią rosnąć bez wyraźnego limitu

Częstym źródłem szybkiego wzrostu są dane techniczne, których użytkownik nie widzi bezpośrednio na stronie.

Wtyczka może przechowywać w bazie na przykład:

logi zdarzeń,
historię synchronizacji,
kolejkę zadań,
statystyki odwiedzin,
logi wysyłki e-maili,
dane webhooków,
cache lub dane tymczasowe.

Jeżeli jedna taka tabela przybywa codziennie o podobną liczbę megabajtów, warto sprawdzić politykę retencji. Możliwe, że plugin przewiduje automatyczne czyszczenie, ale zadanie nie działa, albo retencja została ustawiona znacznie dłużej, niż jest potrzebna.

W przypadku kolejek trzeba uważać szczególnie: duża tabela nie musi zawierać wyłącznie niepotrzebnej historii. Mogą w niej być również zadania oczekujące na wykonanie.

Revisions, transients i dane tymczasowe — co można usuwać bezpieczniej?

WordPress przechowuje rewizje wpisów, a aplikacja i wtyczki mogą korzystać z transientów do czasowego przechowywania danych.

To naturalni kandydaci do kontroli, ale nadal warto rozdzielić trzy sytuacje:

Stare rewizje

Jeżeli strona ma bardzo długą historię edycji, liczba rewizji może być znacząca. Usunięcie części starych wersji zmniejsza jednak historię zmian, więc decyzja powinna uwzględniać sposób pracy redakcji.

Wygasłe transienty

Transient ma określony mechanizm wygasania, ale fizyczne usunięcie wygasłych danych nie zawsze następuje dokładnie w momencie wygaśnięcia. Nagromadzenie dużej liczby starych rekordów może być więc warte sprawdzenia.

Jeżeli witryna korzysta z zewnętrznego persistent object cache, transienty mogą być przechowywane poza bazą, dlatego duże wp_options nie musi wtedy wynikać z ich obecności.

Dane pozostawione przez usunięte wtyczki

Dezaktywacja albo nawet usunięcie pluginu nie gwarantuje, że wszystkie jego tabele i ustawienia zostaną skasowane. Czasami jest to celowe — ponowna instalacja może odzyskać konfigurację.

Przed usunięciem takich danych trzeba jednoznacznie potwierdzić, że komponent nie jest już potrzebny i że nie korzysta z nich nic innego.

OPTIMIZE TABLE nie jest tym samym co usunięcie niepotrzebnych danych

W MySQL i MariaDB operacje optymalizacji tabel mogą reorganizować fizyczne przechowywanie danych i w określonych warunkach odzyskać niewykorzystane miejsce.

Nie rozwiązują jednak problemu logicznego wzrostu. Jeśli plugin codziennie dopisuje sto tysięcy nowych rekordów, OPTIMIZE TABLE nie zastąpi właściwej retencji ani naprawy procesu, który te dane tworzy.

Równie ważne jest rozróżnienie:

rozmiaru logicznych danych — rekordów, które naprawdę istnieją,
miejsca przydzielonego fizycznie — które może nie zmniejszyć się natychmiast po dużym DELETE.

Dlatego po usunięciu wielu rekordów wynik w panelu hostingu nie zawsze spada od razu w taki sposób, jak oczekuje użytkownik.

OPTIMIZE TABLE nie powinno być automatycznym krokiem po każdym czyszczeniu. Dla dużej tabeli InnoDB operacja może oznaczać jej przebudowę i istotne obciążenie serwera, dlatego na hostingu produkcyjnym trzeba ocenić jej koszt i sposób wykonania.

Najpierw zatrzymaj źródło wzrostu, dopiero potem sprzątaj

Jeżeli baza rośnie o 200 MB dziennie, samo jednorazowe usunięcie 2 GB danych daje tylko kilka dni zapasu. Ważniejsze jest znalezienie procesu, który stale dopisuje rekordy.

Przy szybkim wzroście warto wykonać dwa pomiary tej samej tabeli w odstępie czasu. Jeżeli przybywa regularnie, sprawdź komponent odpowiedzialny za zapis i jego konfigurację retencji.

Może się okazać, że problemem nie jest „duża baza WordPressa”, ale:

błąd powodujący masowe logowanie tego samego zdarzenia,
niewykonywane zadanie czyszczące,
kolejka, której worker nie opróżnia,
źle ustawiona retencja statystyk,
integracja zapisująca odpowiedzi bez ograniczenia.

Wtedy właściwa kolejność to: zatrzymać niekontrolowany wzrost, potwierdzić stabilizację, a dopiero później usuwać historyczny nadmiar.

Jak bezpiecznie zmniejszać bazę WordPressa?

Zrób aktualny backup bazy.
Sprawdź rozmiar każdej tabeli.
Wskaż największe tabele i ustal ich właściciela.
Jeśli baza szybko rośnie, wykonaj drugi pomiar po określonym czasie.
Rozdziel dane biznesowe od logów, cache i historii technicznej.
Sprawdź oficjalny mechanizm retencji lub cleanup używanego komponentu.
Najpierw usuń przyczynę nadmiernego wzrostu.
Czyszczenie wykonuj partiami, jeśli tabela jest duża i strona produkcyjna.
Po zmianach sprawdź aplikację oraz rozmiar tabel.

Nie warto zaczynać od przypadkowego zestawu zapytań SQL znalezionego w internecie. Identycznie nazwana tabela na dwóch stronach może zawierać dane używane przez zupełnie inne funkcje.

Jeżeli zbliżasz się do limitu pojemności konta, warto zestawić bazę z innymi składnikami wykorzystania przestrzeni. Pomaga w tym kalkulator pojemności hostingu.

Kiedy większa baza zaczyna być problemem hostingowym?

Sam rozmiar w gigabajtach nie określa jeszcze wydajności. Dwie bazy o podobnej wielkości mogą zachowywać się zupełnie inaczej zależnie od liczby rekordów, indeksów, rodzaju zapytań i aktywności aplikacji.

Problem staje się bardziej związany z hostingiem, gdy:

zbliżasz się do twardego limitu wielkości bazy lub konta,
operator ogranicza liczbę baz albo zasoby MySQL,
duże operacje kończą się timeoutem lub limitem zasobów,
backup i restore przestają mieścić się w dostępnych ograniczeniach środowiska.

Limity warstwy bazodanowej warto wtedy porównać z poradnikiem Limity MySQL na hostingu. Jeżeli występują już okresowe problemy z połączeniem, zobacz również diagnostykę błędu połączenia WordPressa z bazą.

Najważniejsze wnioski

duża baza nie oznacza automatycznie problemu — ważna jest przyczyna i tempo wzrostu;
diagnozę należy zaczynać od rozmiaru poszczególnych tabel, nie od globalnego „optymalizuj bazę”;
wp_postmeta i wp_options mogą rosnąć z powodów całkowicie prawidłowych, dlatego danych nie należy usuwać wyłącznie na podstawie rozmiaru;
przy external object cache transienty mogą znajdować się poza bazą, więc nie należy automatycznie wiązać ich z dużym wp_options;
logi, kolejki, statystyki i cache mogą powiększać bazę bez bezpośredniej wartości dla użytkownika;
przy stałym wzroście ważniejsze jest zatrzymanie źródła nowych rekordów niż jednorazowy cleanup;
OPTIMIZE TABLE nie zastępuje retencji ani usunięcia niepotrzebnych danych i może być kosztowną operacją na dużej tabeli InnoDB;
backup przed czyszczeniem jest ważniejszy niż możliwość odzyskania kilku dodatkowych megabajtów;
duże czyszczenie produkcyjnej bazy warto prowadzić kontrolowanie i weryfikować po każdym etapie.

Źródła

WordPress Developer Resources — Database Description — podstawowe tabele WordPressa i ich przeznaczenie.
WordPress Developer Resources — Options API — przechowywanie ustawień i mechanizm autoload.
WordPress Developer Resources — wp_load_alloptions() — ładowanie opcji autoload i aktualne stany autoload.
Make WordPress Core — Options API: disabling autoload for large options — zmiany autoload i kontrola nadmiernej ilości automatycznie ładowanych danych.
WordPress Developer Resources — Transients API — transienty oraz external persistent object cache.
WordPress Developer Resources — Post Revisions — konfiguracja rewizji.
MySQL 8.4 Reference Manual — OPTIMIZE TABLE — reorganizacja tabel i koszt operacji dla InnoDB.
MySQL 8.4 Reference Manual — InnoDB Disk Management — sposób zarządzania przestrzenią przez InnoDB.