WordPress database cleanup – jak zrobić to bezpiecznie?

WordPress database cleanup nie powinien zaczynać się od kliknięcia „usuń wszystko”. Najpierw wykonaj kopię bazy i plików, zmierz rozmiar tabel oraz sprawdź, które dane rzeczywiście powodują rozrost. Dopiero potem usuwaj rewizje, wygasłe transienty, osierocone metadane lub stare logi – najlepiej małymi partiami i z możliwością odtworzenia zmian.

Dlaczego warto czyścić bazę WordPressa?

Baza danych przechowuje wpisy, strony, ustawienia, komentarze, dane użytkowników, opcje wtyczek oraz metadane. Z czasem mogą do niej trafiać także rewizje, autozapisy, wygasłe transienty, logi i rekordy pozostawione po usuniętych rozszerzeniach.

Nadmiar danych nie zawsze spowalnia każdą stronę w takim samym stopniu, ale może zwiększać rozmiar kopii zapasowych, wydłużać niektóre zapytania i obciążać panel administracyjny. Szczególnej uwagi wymagają tabele wp_options i wp_postmeta. W sklepie WooCommerce duże tabele metadanych mogą być naturalnym skutkiem przechowywania produktów, wariantów i zamówień, więc sama liczba rekordów nie jest powodem do ich kasowania.

Czyszczenie bazy i optymalizacja tabel to dwie różne czynności. Pierwsza usuwa potwierdzone zbędne dane, druga może uporządkować miejsce po operacjach zapisu i usuwania. Żadna z nich nie zastąpi diagnozy wolnych zapytań, wadliwej wtyczki ani źle skonfigurowanego cache.

Bezpieczeństwo przed rozpoczęciem pracy

Operacje DELETE i część działań wykonywanych przez wtyczki są nieodwracalne bez kopii zapasowej. Przed zmianami wykonaj pełny backup bazy oraz plików. Kopia powinna być przechowywana poza tym samym środowiskiem, w którym działa strona.

Nie testuj nieznanych zapytań SQL na produkcji. Najpierw użyj środowiska staging, a każde zapytanie usuwające poprzedź kopią zapasową i kontrolnym SELECT.

Przy dostępie SSH możesz wyeksportować bazę przez WP-CLI:

cd ~/domains/twojadomena.pl/public_html
wp db export backup-before-db-cleanup-$(date +%F-%H%M).sql
ls -lh backup-before-db-cleanup-*.sql

Alternatywą jest eksport w phpMyAdmin, panelu hostingu albo przez mysqldump:

mysqldump -u DB_USER -p DB_NAME > backup-before-db-cleanup.sql

Dane połączenia znajdują się zwykle w wp-config.php, między innymi w stałych DB_NAME, DB_USER, DB_PASSWORD i DB_HOST. Przed użyciem sprawdź, czy pracujesz na właściwej bazie oraz jaki prefiks tabel ustawiono w zmiennej $table_prefix. Nie zakładaj automatycznie, że prefiks to wp_.

Przed czyszczeniem przygotuj środowisko w taki sposób:

• Backup – zapisz kopię bazy i plików oraz sprawdź, czy można ją odtworzyć.
• Staging – przetestuj operacje na kopii strony, szczególnie gdy korzystasz z WooCommerce.
• Okno serwisowe – większe operacje wykonuj poza okresem największego ruchu.
• Dziennik zmian – zanotuj wykonane zapytania, usunięte dane i wyniki pomiarów.

Najpierw zmierz, co zajmuje miejsce

Nie zaczynaj od kasowania. Najpierw ustal rozmiar całej bazy i największych tabel. WP-CLI pozwala zrobić to bezpośrednio w katalogu instalacji:

wp db size --human-readable
wp db size --tables --human-readable

Możesz też użyć zapytania SQL. Działa niezależnie od konkretnego prefiksu tabel:

SELECT
  table_name AS tabela,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS rozmiar_mb,
  table_rows AS przyblizona_liczba_rekordow
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 20;

Po pomiarze sprawdź, który typ danych odpowiada za rozrost. Najczęstsze źródła problemu to:

• duża liczba rewizji i autozapisów w tabeli wpisów,
• wygasłe transienty oraz rozbudowane dane cache zapisane w wp_options,
• duże lub osierocone rekordy w wp_postmeta, wp_commentmeta i wp_usermeta,
• logi, zadania importu i tabele pozostawione przez nieaktywne wtyczki.

Ważna zasada brzmi: najpierw SELECT, później decyzja, a dopiero na końcu DELETE. Wynik kontrolnego zapytania zapisz przed wykonaniem operacji, aby móc porównać stan bazy po zmianach.

Co można czyścić w bazie WordPressa?

Poniższa kolejność ogranicza ryzyko. Po każdym kroku sprawdź działanie strony i nie wykonuj wielu destrukcyjnych operacji jednocześnie.

1. Rewizje – policz je przez wp post list --post_type=revision --format=count albo zapytanie SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision'. Podgląd starszych rekordów wykonaj przed usuwaniem. Przy dużej bazie lepiej usuwać je partiami, na przykład przez WP-CLI. W przyszłości ogranicz ich przyrost w wp-config.php, używając define( 'WP_POST_REVISIONS', 5 );. Nie wyłączaj historii całkowicie, jeśli nad treściami pracuje kilka osób.
2. Transienty – są tymczasowymi danymi używanymi między innymi do cache’owania odpowiedzi API i wyników zapytań. Wygasłe rekordy można usunąć poleceniem wp transient delete --expired. Opcja wp transient delete --all usuwa wszystkie transienty, więc używaj jej tylko wtedy, gdy rozumiesz konsekwencje i masz backup. Ręczne kasowanie z wp_options łatwo może pominąć powiązane rekordy timeoutów.
3. Autoloaded options – opcje ładowane przy każdym żądaniu mogą spowalniać frontend i panel. W starszych instalacjach spotkasz wartości yes i no, a nowsze wersje WordPressa używają także między innymi on, off, auto, auto-on i auto-off. Najpierw sprawdź ich rozmiar i największe rekordy. Nie usuwaj całej tabeli ani nie kasuj opcji tylko dlatego, że wyglądają na stare. Po identyfikacji konkretnej, nieużywanej opcji bezpieczniejszym pierwszym krokiem może być wyłączenie autoload, ale zmianę trzeba przetestować na kopii.
4. Osierocone metadane – najpierw wyszukaj rekordy bez powiązanego wpisu, komentarza lub użytkownika. Przykładowy podgląd dla wp_postmeta wygląda tak: SELECT pm.meta_id, pm.post_id, pm.meta_key FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL LIMIT 50. Dopiero po analizie i backupie rozważ usunięcie. W WooCommerce nie kasuj masowo metadanych, których znaczenia nie potrafisz potwierdzić.

Rozmiar autoloaded options możesz sprawdzić takim zapytaniem:

SELECT
  ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,
  COUNT(*) AS liczba_opcji
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Aby znaleźć największe rekordy bez ich modyfikowania:

SELECT
  option_name,
  autoload,
  ROUND(LENGTH(option_value) / 1024, 2) AS rozmiar_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

Nie zakładaj, że opcja po usuniętej wtyczce jest bezużyteczna. Sprawdź dokumentację rozszerzenia, kod lub staging. W wp_options mogą znajdować się ustawienia motywu, formularzy, buildera, sklepu i integracji.

Jak wybrać metodę czyszczenia?

Ręczny SQL wybierz wtedy, gdy rozumiesz strukturę tabel i potrafisz zweryfikować relacje między rekordami. WP-CLI sprawdza się przy powtarzalnych zadaniach i większej bazie. Wtyczka może być wygodniejsza na prostej stronie, ale nie traktuj przycisku „wyczyść wszystko” jako diagnozy.

Advanced Database Cleaner, WP-Optimize i WP-Sweep mogą pomóc w obsłudze rewizji, transientów, komentarzy, metadanych i optymalizacji tabel. Przed użyciem sprawdź, czy narzędzie pokazuje zakres operacji. Nie instaluj kilku wtyczek wykonujących tę samą funkcję, bo utrudnia to kontrolę zmian.

Optymalizacja tabel i cache obiektowy

Dopiero po usunięciu potwierdzonych zbędnych danych przejdź do optymalizacji tabel. Najpierw możesz sprawdzić ich stan:

wp db check
wp db optimize

W MySQL lub MariaDB można użyć także OPTIMIZE TABLE dla wybranych tabel:

OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

Nie uruchamiaj tej operacji bez planu na największych tabelach w godzinach szczytu. Przy sklepie lub stronie z dużym ruchem może czasowo zwiększyć obciążenie i blokować część operacji.

OPTIMIZE TABLE nie usuwa zbędnych rekordów. To etap porządkowania tabel po czyszczeniu, a nie zamiennik analizy danych.

Jeżeli problemem są powtarzalne zapytania, pomocny może być persistent object cache, na przykład Redis. Przechowuje on często używane obiekty w pamięci i ogranicza liczbę ponownych odwołań do MySQL lub MariaDB. Nie usuwa jednak dużych opcji, osieroconych metadanych ani logów. Query Monitor pozwala sprawdzić, czy obciążenie generuje konkretna wtyczka, motyw, import lub zapytanie typu meta_query.

Sprawdź stronę po czyszczeniu

Po każdej większej zmianie wykonaj test funkcji, które zapisują dane lub korzystają z ustawień w bazie:

• Otwórz frontend i kilka najważniejszych podstron w trybie niezalogowanym.
• Sprawdź logowanie, edycję wpisu i zapis ustawień w panelu administracyjnym.
• Wyślij formularz kontaktowy i potwierdź, że wiadomość została obsłużona.
• W sklepie wykonaj test dodania produktu do koszyka, przejścia do checkoutu i zapisania zamówienia testowego.
• Porównaj czas odpowiedzi panelu, rozmiar tabel i ewentualne błędy PHP lub bazy.

Jeśli po kilku tygodniach ta sama tabela ponownie rośnie bardzo szybko, nie powtarzaj bez końca czyszczenia. Znajdź mechanizm, który ją zapełnia – najczęściej jest to logowanie, import, zadanie cron, integracja albo wtyczka wykonująca ciężkie zapytania.

Bezpieczny WordPress database cleanup to proces, nie jednorazowy przycisk. Backup, pomiar, kontrolny SELECT, małe partie zmian i test działania strony dają znacznie większą kontrolę niż masowe usuwanie danych. Jeśli baza ma rozmiar liczony w gigabajtach albo problemy utrzymują się po podstawowym czyszczeniu, przed kolejnymi operacjami skonsultuj strukturę tabel i zapytania ze specjalistą.