Optymalizacja bazy danych WordPress – jak bezpiecznie odchudzić i przyspieszyć witrynę

Baza danych WordPressa rzadko wysypuje stronę z hukiem. Częściej robi to po cichu: dopisuje kolejne rewizje wpisów, trzyma spam, przechowuje wygasłe transienty, zostawia ustawienia po dawno usuniętych wtyczkach i ładuje coraz więcej danych przy każdym wejściu użytkownika.

Efekt? Kokpit zaczyna mulić, zapis wpisu trwa dłużej niż powinien, kopie zapasowe puchną, a hosting mieli zapytania, które nie dają stronie żadnej realnej wartości. Na froncie czasem jeszcze „jakoś działa”, ale w panelu administracyjnym czuć już beton. Szczególnie w WooCommerce, przy filtrowaniu zamówień, edycji produktów, imporcie danych albo pracy na dużej liczbie pól niestandardowych.

Najważniejsza zasada brzmi: optymalizacja bazy danych WordPress nie polega na klikaniu „wyczyść wszystko”. To nie jest porządkowanie pulpitu. Dobra optymalizacja zaczyna się od kopii zapasowej, rozpoznania tabel i usuwania tylko tych danych, których WordPress naprawdę nie potrzebuje.

Śmietnik w bazie danych: co najbardziej spowalnia Twojego WordPressa

WordPress zapisuje więcej informacji, niż widać w panelu. I dobrze, bo dzięki temu działają rewizje, szkice, ustawienia motywów, konfiguracje wtyczek, koszyki, sesje, formularze i integracje. Problem zaczyna się wtedy, gdy dane techniczne, tymczasowe i historyczne rosną bez kontroli.

Najczęściej winne nie są same wpisy czy strony, ale zaplecze: wp_posts, wp_postmeta, wp_options, komentarze, sesje, logi i tabele po wtyczkach.

Uwaga techniczna: wp_ to tylko domyślny prefiks tabel WordPressa. Na Twojej stronie może to być xyz_options, abc_posts albo zupełnie inny wariant. Faktyczny prefiks sprawdzisz w pliku wp-config.php, w zmiennej:

$table_prefix = 'wp_';

Jeżeli masz inny prefiks, wszystkie zapytania SQL z tego artykułu trzeba odpowiednio podmienić. To drobiazg, ale bardzo ważny. Wklejenie zapytania z wp_options na stronie, która ma prefiks x7s_options, skończy się co najwyżej błędem albo analizą nie tej tabeli, której szukasz.

Najpierw trzeba rozróżnić dwa typy „bałaganu”. Pierwszy to dane zwykle bezpieczne do usunięcia: kosz, spam, automatyczne szkice, stare rewizje, wygasłe transienty. Drugi to dane, które wyglądają podejrzanie, ale mogą być krytyczne: ustawienia aktywnych wtyczek, dane WooCommerce, wpisy w postmeta, rekordy systemów rezerwacji, LMS, formularzy, ACF albo integracji płatniczych. Tego nie usuwa się na oko.

Najczęściej bazę WordPressa obciążają:

• rewizje wpisów – każda większa edycja tworzy kopię poprzedniej wersji; przy pracy redakcyjnej jeden artykuł potrafi mieć kilkadziesiąt rewizji,
• auto-drafts – automatyczne szkice tworzone przez WordPressa, często niepotrzebne po publikacji,
• spam i komentarze w koszu – szczególnie na starszych blogach bez skutecznej ochrony antyspamowej,
• transienty WordPress – tymczasowe dane zapisywane najczęściej w tabeli options, gdy nie działa trwały object cache,
• osierocone meta dane – rekordy w postmeta, usermeta lub commentmeta, które odnoszą się do nieistniejących już wpisów, użytkowników albo komentarzy,
• pozostałości po wtyczkach – opcje, własne tabele i wpisy konfiguracyjne zostawione po odinstalowanych dodatkach,
• autoload w wp_options – dane ładowane automatycznie przy każdym żądaniu strony.

Największy priorytet ma zwykle wp_options autoload, bo te dane są pobierane bardzo wcześnie. Jeżeli wtyczka zapisze tam wielki pakiet konfiguracji z autoload = yes, WordPress będzie ładował go nawet wtedy, gdy dana funkcja jest potrzebna tylko w jednym miejscu, np. w koszyku, formularzu kontaktowym albo panelu administratora.

Pierwszy audyt można zacząć od prostego zapytania:

SELECT 
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb,
  COUNT(*) AS liczba_rekordow
FROM wp_options
WHERE autoload = 'yes';

Jeżeli Twoja tabela ma inny prefiks, użyj właściwej nazwy, np.:

FROM xyz_options

Potem warto sprawdzić największe rekordy ładowane automatycznie:

SELECT 
  option_name,
  ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

To nadal nie jest instrukcja kasowania. To diagnoza. Jeżeli na górze listy pojawia się opcja aktywnej wtyczki płatności, WooCommerce, systemu rezerwacji, cache obiektowego albo motywu, nie wolno jej usuwać bez sprawdzenia. Jeżeli natomiast widzisz rekordy po wtyczce, której nie ma na stronie od dwóch lat, masz kandydata do ręcznej weryfikacji.

W swojej pracy wielokrotnie reanimowałem sklepy, w których domorosły optymalizator wyczyścił wp_options na ślepo, kładąc cały checkout, konfigurację bramki płatności, SMTP, pola ACF albo integrację z kurierem. Baza była mniejsza. Tylko że zamówień nie dało się już złożyć.

Dlatego kolejność jest prosta: najpierw sprawdzasz, potem rozumiesz, dopiero na końcu usuwasz.

Jak bezpiecznie oczyścić tabelę wp_options i ograniczyć rewizje wpisów

Bezpieczeństwo zaczyna się przed czyszczeniem. Nie po. Przed każdą ingerencją w bazę trzeba mieć świeżą kopię plików i bazy danych oraz wiedzieć, jak ją przywrócić. Sam komunikat w panelu hostingu „backup aktywny” nie wystarcza. Liczy się to, czy kopia obejmuje aktualną bazę i czy da się ją odtworzyć bez pisania dramatycznego maila do supportu o drugiej w nocy.

Minimalna procedura przed optymalizacją:

• wykonaj pełny backup bazy i plików,
• sprawdź, czy masz dostęp do phpMyAdmin, Adminera, panelu hostingu albo WP-CLI,
• zrób czyszczenie najpierw na stagingu, jeżeli strona zarabia, obsługuje zamówienia albo ma duży ruch,
• nie usuwaj rekordów związanych z aktywnymi wtyczkami bez dokumentacji lub testu,
• po sprzątaniu sprawdź logowanie, formularze, koszyk, płatności, wysyłkę maili, cron i panel administracyjny.

Tabela wp_options wymaga największej ostrożności, bo przechowuje ustawienia WordPressa, motywu i wtyczek. Nie jest śmietnikiem z definicji. Problemem są przede wszystkim wygasłe transienty, zbyt duże dane z autoload oraz stare opcje po usuniętych dodatkach.

Transienty rozpoznasz po nazwach:

_transient_...
_transient_timeout_...
_site_transient_...
_site_transient_timeout_...

Wygasłe transienty zwykle można usuwać bezpiecznie, bo WordPress i wtyczki powinny umieć je odtworzyć. Nie robiłbym jednak agresywnego czyszczenia wszystkich transientów w sklepie w trakcie kampanii reklamowej. Koszyki, sesje, zapytania do API, integracje płatności i dane tymczasowe wtyczek potrafią być bardziej kapryśne, niż sugeruje nazwa „tymczasowe”.

Bezpieczne czyszczenie wygasłych transientów przez WP-CLI:

wp transient delete --expired

To usuwa tylko dane, które przekroczyły czas ważności. Kasowanie wszystkich transientów też bywa dopuszczalne, ale po takiej operacji strona może przez chwilę wykonywać więcej zapytań, bo będzie odbudowywać dane tymczasowe.

Jeśli masz dość ciągłego czyszczenia transientów z tabeli wp_options, wdróż Redis albo Memcached wraz z wtyczką do Object Cache. Przy poprawnie skonfigurowanym trwałym cache obiektowym WordPress może przechowywać dane tymczasowe w pamięci RAM serwera, zamiast zapisywać je w MySQL. To nie jest kosmetyka. Na stronach z dużą liczbą zapytań, WooCommerce, rozbudowanymi filtrami produktów albo ciężkimi integracjami różnica potrafi być odczuwalna w TTFB i obciążeniu bazy.

Trzeba jednak znać ograniczenie: cache w RAM nie jest archiwum. Redis lub Memcached mogą usuwać dane pod presją pamięci, po restarcie usługi albo zgodnie z ustawioną polityką eksmisji. Dlatego nie każda wtyczka powinna traktować transient jak pewny magazyn danych. Dobrze napisana integracja poradzi sobie z odbudową cache. Źle napisana potrafi zacząć sypać błędami po czyszczeniu.

Drugi duży temat to rewizje WP. Są przydatne, gdy redakcja pracuje nad treścią i trzeba wrócić do poprzedniej wersji. Nie są przydatne, gdy baza trzyma 80 kopii każdego wpisu sprzed trzech lat.

Najrozsądniejsza decyzja graniczna: nie wyłączać rewizji całkowicie, tylko je ograniczyć. W pliku wp-config.php, przed linią:

/* That's all, stop editing! Happy publishing. */

dodaj:

define( 'WP_POST_REVISIONS', 5 );

To oznacza, że WordPress zachowa maksymalnie 5 rewizji dla wpisu. Dla bloga, strony firmowej i większości serwisów contentowych to wystarczający bufor. Przy intensywnej pracy redakcyjnej można ustawić 10. Wyłączenie rewizji:

define( 'WP_POST_REVISIONS', false );

ma sens tylko na stronach, gdzie treści są rzadko edytowane, a każda zmiana i tak przechodzi przez zewnętrzny proces akceptacji. Na blogu, portalu lub stronie z kilkoma autorami to zły układ: jeden błędny zapis i nie ma do czego wrócić.

Można też wydłużyć interwał autozapisu:

define( 'AUTOSAVE_INTERVAL', 180 );

Wartość podaje się w sekundach. Domyślnie WordPress zapisuje szkic często, co chroni autora przed utratą pracy. Ustawienie 180 sekund ogranicza liczbę automatycznych zapisów, ale nie jest agresywne. Ustawianie bardzo wysokich wartości tylko po to, żeby „nie rosła baza”, jest słabą decyzją. Wystarczy awaria przeglądarki i autor traci kilkanaście minut pracy.

Dodatkowo można skrócić czas przechowywania elementów w koszu:

define( 'EMPTY_TRASH_DAYS', 7 );

To dobre ustawienie dla stron, gdzie administratorzy świadomie usuwają treści. Jeżeli z panelem pracuje wiele osób, lepiej nie schodzić zbyt nisko. Kosz bywa ostatnią deską ratunku po przypadkowym kliknięciu.

Stare rewizje można usunąć przez WP-CLI:

wp post delete $(wp post list --post_type='revision' --format=ids) --force

To polecenie jest skuteczne, ale bezlitosne: usuwa wszystkie rewizje. Dla większości stron lepsza jest wtyczka, która pozwala zostawić ostatnie rewizje i skasować tylko starsze. Jeżeli mimo wszystko robisz to ręcznie, wykonaj operację na stagingu albo przynajmniej po pełnym backupie.

Po czyszczeniu można zoptymalizować tabele MySQL/MariaDB, ale nie traktuj tego jak magicznego przyspieszacza. OPTIMIZE TABLE może odzyskać miejsce i uporządkować fizyczny zapis danych, lecz na dużych tabelach potrafi być operacją ciężką.

Przykład:

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments, wp_commentmeta;

I tutaj ważne ostrzeżenie dla większych serwisów: przy tabelach InnoDB OPTIMIZE TABLE wykonuje przebudowę tabeli. W praktyce może to oznaczać utworzenie tymczasowej kopii tabeli, dodatkowe zużycie miejsca na dysku i blokady wpływające na zapis danych. Jeżeli masz sklep e-commerce, dużą tabelę postmeta, tabelę zamówień albo własne tabele z setkami tysięcy rekordów, taka operacja odpalona w środku dnia potrafi zamrozić zapis, wysypać checkout albo doprowadzić bazę do braku miejsca.

Dla dużych baz bezpieczniejsze są trzy ścieżki:

• wykonanie operacji w nocy, w oknie serwisowym,
• wcześniejszy test na stagingu z kopią produkcyjnej bazy,
• użycie narzędzi typu pt-online-schema-change, gdy trzeba ograniczyć blokady na produkcji.

Nie każdy hosting współdzielony pozwoli użyć Percona Toolkit, więc czasem realna decyzja brzmi: nie kombinować samemu, tylko zlecić operację administratorowi serwera albo wykonać ją przez support hostingu.

Najlepsze wtyczki i metody manualne do regularnej optymalizacji bazy

Najpierw priorytety. Dla większości właścicieli stron najlepsza kolejność działań wygląda tak:

1. backup,
2. czyszczenie oczywistych danych: spam, kosz, auto-szkice, stare rewizje,
3. usunięcie wygasłych transientów,
4. analiza wp_options i autoload,
5. dopiero potem usuwanie osieroconych danych i porządkowanie tabel.

Wtyczki są wygodne, ale nie zwalniają z myślenia. Dobra wtyczka pokazuje, co usuwa, pozwala wykluczyć dane z czyszczenia i umożliwia harmonogram. Słaba daje wielki przycisk „Clean all” i zostawia administratora z konsekwencjami.

WP-Optimize sprawdza się, gdy chcesz sprzątać bazę z poziomu panelu i nie potrzebujesz od razu rozbierać każdej tabeli na śrubki. Wtyczka pozwala czyścić typowe śmieci, usuwać zbędne dane i optymalizować tabele. Ma też funkcje cache, kompresji obrazów i minifikacji, ale przy tym artykule interesuje nas tylko moduł bazy danych. Na stronach, które mają już osobny system cache, trzeba uważać, żeby nie włączyć przypadkiem drugiej warstwy mechanizmów optymalizacyjnych. Dublowanie cache potrafi dać więcej dziwnych błędów niż realnego zysku.

Advanced Database Cleaner jest bardziej techniczny i lepiej pasuje do stron po latach instalowania oraz usuwania wtyczek. Pozwala sprzątać rewizje, auto-szkice, transienty, osierocone dane i nieużywane tabele. To narzędzie dla osoby, która chce widzieć, co siedzi w bazie, a nie tylko dostać zielony komunikat „database optimized”. Jednocześnie wymaga większej ostrożności, bo im więcej kontroli, tym łatwiej usunąć coś, czego się nie rozumie.

WP-Sweep jest lżejszy i dobry dla prostych stron firmowych, blogów oraz mniejszych serwisów. Nie próbuje być kombajnem do wszystkiego. Sprząta typowe dane WordPressa i nie zasypuje użytkownika dziesiątkami agresywnych opcji. Jeżeli jednak baza jest mocno zanieczyszczona po wielu wtyczkach, sam WP-Sweep może być zbyt delikatny.

Optimize Database after Deleting Revisions ma węższe zastosowanie, ale właśnie dlatego bywa przydatny. Jeżeli głównym problemem są tysiące starych wersji wpisów, a nie chaos po wtyczkach, takie narzędzie załatwia konkretną sprawę bez dokładania kolejnego kombajnu do panelu.

Metody manualne są lepsze, gdy trzeba diagnozować konkretny problem, a nie tylko „odchudzić bazę”. Jeżeli panel ładuje się wolno, WooCommerce mieli zamówienia, a zapytania do options są podejrzanie ciężkie, wtyczka może pokazać objawy, ale nie zawsze pokaże przyczynę.

Przydatne polecenia WP-CLI:

wp db size --tables

Pokazuje rozmiary tabel. Dzięki temu od razu widać, czy problemem jest postmeta, options, tabela logów, czy niestandardowa tabela konkretnej wtyczki.

wp transient delete --expired

Czyści wygasłe transienty.

wp db optimize

Uruchamia optymalizację tabel. Na dużej produkcji ostrożnie — najlepiej poza godzinami ruchu.

Przydatne zapytanie do wyszukania największych tabel:

SELECT 
  table_name AS tabela,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;

To zapytanie często od razu pokazuje winowajcę. Jeżeli największa jest tabela logów po wtyczce bezpieczeństwa, nie ma sensu zaczynać od rewizji. Jeżeli ogromne jest wp_postmeta, trzeba sprawdzić, czy problemem są produkty WooCommerce, pola ACF, importy, warianty produktów czy osierocone rekordy. Jeżeli puchnie wp_options, priorytetem jest autoload, transienty i stare opcje po wtyczkach.

Harmonogram czyszczenia powinien zależeć od typu strony:

• blog lub strona firmowa: raz na miesiąc albo po większych zmianach treści,
• sklep WooCommerce: lekki przegląd co 2–4 tygodnie, głębsza optymalizacja w oknie serwisowym,
• portal z wieloma autorami: ograniczenie rewizji od razu, czyszczenie cykliczne co tydzień lub co miesiąc,
• strona po migracji lub redesignie: jednorazowy audyt bazy, bo właśnie wtedy zostaje najwięcej śladów po starych wtyczkach i motywach.

Nie wszystko trzeba automatyzować. Automatyczne usuwanie spamu, kosza i wygasłych transientów jest rozsądne. Automatyczne usuwanie osieroconych tabel już niekoniecznie, bo wtyczka może uznać za nieużywaną tabelę, która należy do czasowo wyłączonego modułu. W produkcji wolę mniej automatyzacji i więcej kontroli niż piękny harmonogram, który raz w tygodniu może skasować coś ważnego.

Najbezpieczniejszy plan działania wygląda tak:

1. Najpierw ogranicz nowe śmieci: ustaw limit rewizji WP w wp-config.php.
2. Potem usuń dane oczywiste: spam, kosz, auto-szkice, wygasłe transienty.
3. Następnie sprawdź wp_options, szczególnie autoload.
4. Przy częstych problemach z transientami rozważ Redis lub Memcached jako trwały Object Cache.
5. Dopiero na końcu ruszaj osierocone meta dane i nieużywane tabele.
6. Po każdej większej operacji testuj stronę, zamiast robić dziesięć zmian naraz.

Jeżeli po czyszczeniu baza zmniejszy się o 20–40%, to dobry wynik. Jeżeli nie zmniejszy się prawie wcale, to też informacja: problem może leżeć w architekturze strony, liczbie produktów, logach, zapytaniach meta albo hostingu, a nie w klasycznym „śmietniku”. Optymalizacja bazy danych WordPress poprawia warunki pracy strony, ale nie naprawia źle napisanej wtyczki ani serwera przeciążonego ponad limit.

FAQ: najczęstsze pytania o czyszczenie bazy danych WordPress

Co zrobić z tabelami po usuniętych wtyczkach, których nie wykrywa zwykły Cleaner?
Najpierw zidentyfikuj, do jakiej wtyczki należała tabela. Często zdradza to nazwa, np. fragment prefiksu w stylu rank_math, woocommerce, actionscheduler, mailpoet, aioseo albo nazwa starego formularza. Jeżeli masz pewność, że wtyczka nie działa i tabela nie jest już używana, usuń ją przez phpMyAdmin komendą DROP TABLE nazwa_tabeli; albo przez WP-CLI. Przed usunięciem zrób eksport tej konkretnej tabeli, bo DROP TABLE nie przenosi danych do kosza — kasuje je od razu.

Czy baza danych ma wpływ na błąd „Error Establishing a Database Connection”?
Tak. Ten błąd nie zawsze oznacza złe hasło do bazy. Jeżeli baza jest przeładowana, zapytania trwają zbyt długo, a serwer MySQL dobija do limitu jednoczesnych połączeń max_connections, WordPress może nie dostać połączenia na czas. W sklepach dzieje się to często przy dużym ruchu, ciężkich filtrach produktów, źle działającym cronie albo tabelach logów, które urosły bez kontroli.

Jak często wykonywać optymalizację bazy WordPressa?
Na prostej stronie firmowej wystarczy raz w miesiącu. W sklepie WooCommerce lub portalu z wieloma autorami lepiej robić lżejsze czyszczenie częściej, a cięższe operacje, takie jak OPTIMIZE TABLE, planować poza godzinami największego ruchu. Jeżeli tabela ma kilka gigabajtów, nie odpalaj optymalizacji „przy okazji” z panelu wtyczki.

Czy wp_options można czyścić ręcznie w phpMyAdmin?
Można, ale tylko wtedy, gdy wiesz, za co odpowiada konkretny rekord. Sama duża wartość w option_value nie oznacza, że opcja jest zbędna. Najpierw sprawdź największe rekordy z autoload = 'yes', potem ustal, do której wtyczki należą, a dopiero później podejmij decyzję. Przy niestandardowym prefiksie tabel pamiętaj, że wp_options może nazywać się inaczej.

Czy usunięcie transientów przyspieszy stronę?
Może pomóc, zwłaszcza gdy w bazie zalegają tysiące wygasłych transientów. Nie gwarantuje jednak trwałego przyspieszenia. Jeżeli wtyczka stale tworzy nowe ciężkie transienty albo cron WordPressa nie działa poprawnie, problem wróci. Przy powtarzającym się problemie lepszym kierunkiem jest Redis lub Memcached jako trwały object cache.

Od czego zacząć, jeśli baza WordPressa jest bardzo duża?
Zacznij od sprawdzenia rozmiarów tabel. Nie zgaduj. Jeżeli największe jest wp_options, analizuj autoload i transienty. Jeżeli wp_postmeta, sprawdź dane produktów, pól niestandardowych, wariantów i osierocone meta rekordy. Jeżeli największa jest tabela konkretnej wtyczki, zacznij od jej ustawień retencji logów albo dokumentacji.

Czy sama optymalizacja bazy wystarczy, żeby strona była szybka?
Nie. Baza to tylko jeden element. Jeżeli problemem jest słaby hosting, ciężki motyw, źle napisane zapytania albo przeciążone WooCommerce, czyszczenie pomoże ograniczyć bałagan, ale nie usunie głównej przyczyny. Najpierw usuń oczywisty śmietnik, potem diagnozuj największe tabele, najwolniejsze zapytania i realne limity serwera.

Najlepszy pierwszy krok jest prosty: wykonaj backup, sprawdź rozmiary tabel i ogranicz rewizje w wp-config.php. Dopiero potem czyść. WordPress zwykle nie potrzebuje rewolucji w bazie — potrzebuje regularnego sprzątania, rozsądnego object cache i niewciskania przycisku „usuń wszystko”, gdy nie wiadomo, co dokładnie zniknie.