Jak zoptymalizować bazę danych WordPress?

Optymalizacja bazy danych WordPress nie polega na kliknięciu jednego przycisku. Bezpieczny proces wygląda tak: najpierw backup, potem diagnoza i zapytania SELECT, następnie kontrolowane czyszczenie, a dopiero na końcu optymalizacja tabel. Takie podejście ogranicza ryzyko usunięcia ustawień wtyczek, danych sklepu WooCommerce albo rekordów potrzebnych do działania strony.

Od czego zacząć optymalizację bazy WordPress?

Przed każdą operacją wykonaj kopię bazy danych oraz plików strony. Backup bazy możesz zrobić przez panel hostingu, phpMyAdmin, WP-CLI albo mysqldump. Jeżeli masz dostęp do SSH, przykładowy eksport przez WP-CLI wygląda tak:

# Eksport bazy z datą i godziną w nazwie pliku
wp db export backup-before-db-cleanup-$(date +%F-%H%M).sql

# Sprawdzenie, czy plik powstał
ls -lh backup-before-db-cleanup-*.sql

W przypadku większej instalacji przetestuj odtworzenie kopii na środowisku stagingowym. Sama obecność pliku backupu nie oznacza jeszcze, że można go poprawnie przywrócić.

Przed rozpoczęciem przygotuj też:

• Kopię bazy danych zapisaną poza serwerem produkcyjnym.
• Kopię plików, szczególnie wp-content i wp-config.php.
• Środowisko stagingowe do sprawdzenia operacji na kopii strony.
• Plan cofnięcia zmian, czyli wiedzę, jak przywrócić bazę i pliki.

Zapamiętaj prostą regułę administracyjną: backup → SELECT → decyzja → DELETE. Nie wykonuj polecenia usuwającego tylko dlatego, że tabela wygląda na dużą.

Jak sprawdzić, co zajmuje miejsce?

Najpierw zmierz rozmiar całej bazy i poszczególnych tabel. WP-CLI pozwala szybko uzyskać podstawowe informacje:

# Rozmiar całej bazy
wp db size --human-readable

# Rozmiar tabel
wp db size --tables --human-readable

W phpMyAdmin możesz użyć zapytania SQL. Prefiks wp_ jest tylko przykładem, ponieważ instalacja może korzystać z innego prefiksu zdefiniowanego w wp-config.php.

-- Lista 20 największych tabel według danych i indeksów
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;

Sama wielkość tabeli nie wskazuje jeszcze, że można ją wyczyścić. Znaczenie ma rodzaj przechowywanych danych.

W sklepie WooCommerce duże wp_postmeta nie musi oznaczać awarii. Produkty, warianty, zamówienia i integracje często korzystają z wielu metadanych. Nie kasuj ich bez znajomości schematu konkretnej wtyczki.

Jak usunąć rewizje, szkice i spam?

Rewizje są wcześniejszymi wersjami wpisów i stron. Przy częstej edycji mogą zajmować dużo miejsca, ale całkowite ich usunięcie pozbawia zespół historii zmian. Bezpieczniejsza jest kontrola liczby rewizji.

1. Sprawdź liczbę rewizji – użyj wp post list --post_type=revision --format=count albo zapytania SQL.
2. Wykonaj backup – nie usuwaj rekordów przed utworzeniem kopii bazy.
3. Wyświetl kandydatów do usunięcia – sprawdź identyfikatory, daty i wpisy nadrzędne.
4. Usuń dane partiami – po każdej operacji przetestuj panel i edycję treści.

# Liczba rewizji, bez usuwania danych
wp post list --post_type=revision --format=count

# Podgląd rewizji starszych niż 90 dni
wp post list \
  --post_type=revision \
  --date_query_column=post_date \
  --before='90 days ago' \
  --fields=ID,post_parent,post_date,post_title \
  --format=table \
  --posts_per_page=20

Możesz również użyć SQL, ale najpierw wykonaj wyłącznie zapytanie podglądowe:

-- Podgląd rewizji starszych niż 90 dni
SELECT ID, post_parent, post_date, post_title
FROM wp_posts
WHERE post_type = 'revision'
  AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY)
ORDER BY post_date ASC
LIMIT 50;

Jeśli wynik jest zgodny z oczekiwaniem, po backupie możesz usunąć takie rekordy. Przy dużej bazie lepiej wykonywać operację partiami albo użyć WP-CLI, który pozwala kontrolować zakres.

-- Usunięcie rewizji starszych niż 90 dni
-- Wykonuj dopiero po backupie i sprawdzeniu SELECT
DELETE FROM wp_posts
WHERE post_type = 'revision'
  AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

Limit przyszłych rewizji ustaw w wp-config.php, przed komentarzem kończącym plik:

// Maksymalnie 5 rewizji na wpis lub stronę
define( 'WP_POST_REVISIONS', 5 );

// Automatyczne opróżnianie kosza po 14 dniach
define( 'EMPTY_TRASH_DAYS', 14 );

Nie wyłączaj rewizji całkowicie na stronie, na której kilka osób wspólnie redaguje treści. Ograniczenie ich liczby jest zwykle rozsądniejszym kompromisem.

Jak uporządkować wp_options i transienty?

Tabela wp_options przechowuje ustawienia WordPressa, motywów i wtyczek. Szczególne znaczenie mają autoloaded options, czyli opcje ładowane przy każdym żądaniu. Ich nadmiar może spowalniać frontend i panel administracyjny.

W nowszych wersjach WordPressa spotkasz nie tylko wartości yes i no, ale także między innymi on, off, auto, auto-on i auto-off. Dlatego diagnostyka nie powinna sprawdzać wyłącznie autoload = 'yes'.

-- Łączny rozmiar automatycznie ładowanych opcji
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');

-- Największe automatycznie ładowane opcje
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 usuwaj całej zawartości wp_options. Nazwa opcji może wyglądać niepozornie, a mimo to być potrzebna do działania sklepu, formularza, buildera lub integracji. Jeśli duża opcja pochodzi ze starej wtyczki, najpierw sprawdź dokumentację i wykonaj test na kopii.

Czasem bezpieczniejszym rozwiązaniem jest wyłączenie autoloadowania, a nie usunięcie rekordu:

-- Podgląd konkretnej opcji
SELECT
    option_id,
    option_name,
    autoload,
    LENGTH(option_value) AS bajty
FROM wp_options
WHERE option_name = 'nazwa_duzej_opcji';

-- Zmiana tylko po potwierdzeniu, że opcja nie jest potrzebna przy każdym żądaniu
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'nazwa_duzej_opcji';

Transienty przechowują dane tymczasowe, takie jak cache odpowiedzi API lub wyniki obliczeń. Wygasłe rekordy możesz usuwać przez WP-CLI:

# Usunięcie wyłącznie wygasłych transientów
wp transient delete --expired

# Usunięcie wszystkich transientów, ostrożnie i najlepiej poza szczytem ruchu
wp transient delete --all

Przed ręcznym usuwaniem transientów sprawdź ich skalę:

-- Liczba rekordów transientów
SELECT COUNT(*) AS liczba_transientow
FROM wp_options
WHERE option_name LIKE '_transient_%'
   OR option_name LIKE '_site_transient_%';

-- Podgląd wygasłych timeoutów
SELECT option_name, option_value AS timeout_unix
FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
  AND option_value < UNIX_TIMESTAMP()
ORDER BY option_value ASC
LIMIT 50;

WP-CLI albo narzędzie pokazujące podgląd danych jest bezpieczniejszym wyborem niż szerokie zapytanie DELETE. Nie usuwaj opcji tylko na podstawie nazwy bez sprawdzenia, z jaką funkcją są związane.

Jak znaleźć osierocone metadane i logi?

Osierocone metadane to rekordy, których wpis nadrzędny już nie istnieje. Najpierw wykonaj podgląd, a dopiero po backupie rozważ usunięcie.

-- Podgląd osieroconych metadanych wpisów
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;

-- Przykładowe usunięcie po weryfikacji wyniku
DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Analogicznie możesz sprawdzić metadane komentarzy i użytkowników:

-- Osierocone metadane komentarzy
SELECT cm.meta_id, cm.comment_id, cm.meta_key
FROM wp_commentmeta cm
LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id
WHERE c.comment_ID IS NULL
LIMIT 50;

-- Osierocone metadane użytkowników
SELECT um.umeta_id, um.user_id, um.meta_key
FROM wp_usermeta um
LEFT JOIN wp_users u ON u.ID = um.user_id
WHERE u.ID IS NULL
LIMIT 50;

W WooCommerce zachowaj szczególną ostrożność. Metadane produktów, wariantów i zamówień mogą wyglądać jak zwykłe rekordy, ale ich usunięcie może zmienić działanie sklepu lub utrudnić odczyt historycznych zamówień.

Sprawdź też tabele tworzone przez wtyczki, logi i zadania cron. Po dezaktywacji rozszerzenia dane nie zawsze są automatycznie kasowane, ponieważ producent może pozostawiać je na wypadek ponownej instalacji.

• Sprawdź nazwę i właściciela dużej tabeli.
• Ustal, czy tabela przechowuje logi, cache, importy czy dane operacyjne.
• Poszukaj ustawienia retencji w konkretnej wtyczce.
• Nie usuwaj tabeli, jeśli nie potrafisz odtworzyć jej przeznaczenia.

Czym różni się czyszczenie od optymalizacji tabel?

Czyszczenie usuwa rekordy, których nie potrzebujesz, na przykład stare rewizje lub wygasłe transienty. Optymalizacja tabel jest operacją techniczną. Polecenie OPTIMIZE TABLE może uporządkować strukturę tabeli i odzyskać wolne miejsce po licznych operacjach zapisu i usuwania.

Najpierw wykonaj czyszczenie, potem sprawdź bazę i dopiero wtedy optymalizuj wybrane tabele:

# Kontrola integralności tabel przez WP-CLI
wp db check

# Optymalizacja tabel
wp db optimize

W MySQL lub MariaDB możesz wskazać konkretne tabele:

-- Wykonuj po backupie, najlepiej poza szczytem ruchu
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;

Nie uruchamiaj tej operacji bez potrzeby na największej tabeli sklepu w godzinach szczytu. Przy dużej bazie operacja może zużywać zasoby i czasowo wpływać na dostępność strony.

Wtyczka, WP-CLI czy SQL?

Wtyczka jest wygodna, ale nie jest automatycznie bezpieczna. Przed użyciem wykonaj backup i nie instaluj kilku narzędzi czyszczących jednocześnie. WP-CLI sprawdzi się przy regularnej administracji, a SQL zostaw dla operacji, których zakres potrafisz dokładnie określić.

Co zrobić, gdy baza nadal działa wolno?

Mała baza nie gwarantuje szybkiej strony. Problemem może być konkretne zapytanie, wtyczka, motyw, import, filtr produktów albo rozbudowane meta_query. Query Monitor pomaga ustalić, które zapytania trwają długo i jaki komponent WordPressa je wywołuje.

Przy analizie konkretnego zapytania możesz użyć EXPLAIN, ale nie dodawaj indeksów na produkcji bez pomiaru. Indeks może przyspieszyć odczyt, lecz zwiększa rozmiar tabeli i koszt operacji zapisu.

-- Analiza planu wykonania zapytania
EXPLAIN
SELECT p.ID, p.post_title
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID
WHERE p.post_type = 'product'
  AND p.post_status = 'publish'
  AND pm.meta_key = '_sku'
  AND pm.meta_value = 'ABC-123';

Jeżeli WordPress wielokrotnie pobiera te same dane, rozważ persistent object cache, na przykład Redis. Redis przechowuje często używane dane w pamięci i może ograniczyć liczbę powtarzalnych zapytań do MySQL lub MariaDB. Nie zastępuje jednak czyszczenia wp_options, usuwania osieroconych metadanych ani naprawy źle działającej wtyczki.

Po każdej większej zmianie sprawdź:

• stronę główną i najważniejsze podstrony,
• logowanie oraz panel administracyjny,
• formularze i wysyłkę wiadomości,
• koszyk, płatności i checkout w WooCommerce,
• zadania cron oraz integracje zewnętrzne.

Prosty dziennik zmian ułatwia ocenę, czy problem wraca:

# Zapis podstawowych pomiarów po operacji
echo "Data: $(date)" >> db-cleanup-log.txt
wp db size --human-readable >> db-cleanup-log.txt
wp db size --tables --human-readable >> db-cleanup-log.txt
wp post list --post_type=revision --format=count >> db-cleanup-log.txt

Regularna kontrola ma sens częściej na aktywnym blogu, portalu i sklepie WooCommerce, zwłaszcza po importach lub zmianach wtyczek. Przy bazie liczącej kilka gigabajtów albo bez umiejętności przywrócenia backupu lepiej zlecić operację administratorowi.

Najbezpieczniejsza procedura to pomiar, kopia zapasowa, analiza SELECT, czyszczenie małymi partiami, testy i dopiero potem OPTIMIZE TABLE. Jeśli baza pozostaje wolna po uporządkowaniu danych, szukaj problemu w zapytaniach, logach, cronach, cache i konfiguracji wtyczek, a nie tylko w rozmiarze tabel.