Optymalizacja bazy danych WordPress - co czyścić, a czego nie ruszać

Panel WordPressa mieli przy każdym zapisie. Koszyk w sklepie otwiera się kilka sekund. Wtyczka do „optymalizacji jednym kliknięciem” kusi wielkim przyciskiem.

Krótka odpowiedź: zrób kopię bazy, zmierz, co naprawdę zajmuje miejsce, wyczyść tylko to, co jest bezpieczne, i przetestuj stronę po zmianie. Bezpieczne do czyszczenia są zwykle stare rewizje, wygasłe transienty, spam, kosz i autoszkice. Ostrożnie, z planem, ruszasz autoload w wp_options, tabele po wtyczkach, indeksy, Action Scheduler i stare dane zamówień po HPOS. Czego nie ruszasz wcale: tabel aktywnych wtyczek i niczego, czego właściciela nie znasz.

I jedna rzecz, której wiele poradników nie mówi. Czysta baza nie naprawi wolnego serwera ani ciężkiego buildera. Dlatego zaczynam od pomiaru, a nie od czyszczenia.

Zanim cokolwiek usuniesz - kopia i pomiar

Kopia bazy

Każda operacja usuwania w bazie jest nieodwracalna. Kosz w panelu WordPressa nie obejmuje rewizji, transientów ani tabel. Jedyną drogą powrotu jest kopia.

Jeśli masz dostęp do SSH i WP-CLI, kopię zrobisz dwiema komendami:

mkdir -p ~/kopie-bazy && chmod 700 ~/kopie-bazy
wp db export ~/kopie-bazy/kopia-przed-czyszczeniem.sql

Zapisuję kopię w osobnym katalogu poza folderem publicznym strony (na przykład poza public_html). Plik .sql zapisany w katalogu strony może pobrać z przeglądarki każdy, kto zgadnie jego nazwę, a to cała baza, łącznie z kontami użytkowników i zamówieniami. Na niektórych hostingach katalog domowy jest jednocześnie katalogiem strony, więc sprawdź to przed eksportem. Potem pobierz plik na swój komputer (np. przez SFTP) i usuń go z serwera po zakończeniu prac.

Bez SSH zrób kopię w panelu hostingu albo wtyczką do kopii zapasowych. Trzymaj ją poza serwerem i sprawdź, czy da się ją przywrócić. Kopia, której nigdy nie przywracałeś, jest tylko nadzieją. Jak to zrobić krok po kroku, opisuję w poradniku o kopiach zapasowych WordPressa.

Na sklepie z ruchem najbezpieczniej przećwiczyć całe czyszczenie na kopii strony (stagingu), a dopiero potem powtórzyć je na produkcji, w godzinach z najmniejszą liczbą zamówień.

Prefiks tabel

Wszystkie przykłady SQL w tym wpisie używają domyślnego prefiksu wp_. Twoja baza może mieć inny, na przykład wpx7_. Sprawdzisz go w pliku wp-config.php, w linii z $table_prefix, albo na liście tabel w phpMyAdmin.

Zapytania poniżej to wyłącznie SELECT, czyli odczyt. Niczego nie zmieniają. Mimo to uruchamiaj je po zrobieniu kopii i podmień prefiks, zanim klikniesz „Wykonaj”.

Diagnoza - co naprawdę zajmuje miejsce w bazie

Rozmiar tabel

Zacznij od listy największych tabel. To od razu pokazuje, czy problemem są wpisy, opcje, logi wtyczek, czy zadania w tle sklepu.

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

Liczba wierszy w InnoDB jest tu szacunkiem, nie dokładnym licznikiem. Do porównania „co jest największe” wystarczy.

To samo w WP-CLI:

wp db size --tables

Typowe wyniki i co znaczą:

• wp_options duże przy małej stronie: prawie zawsze autoload albo transienty.
• wp_postmeta i wp_posts największe: rewizje, dużo produktów albo stare zamówienia sprzed HPOS.
• wp_actionscheduler_actions i wp_actionscheduler_logs duże: kolejka zadań WooCommerce i wtyczek, opisana niżej.
• Tabela z nazwą wtyczki, której już nie masz: kandydat do usunięcia, ale dopiero po sprawdzeniu.

Autoload w wp_options

Opcje z włączonym autoload WordPress ładuje przy każdym wyświetleniu strony, także w panelu. Jeśli wtyczka zapisze tam kilka megabajtów, płacisz za to przy każdym żądaniu, którego nie obsłuży cache strony: w panelu, w koszyku, na koncie klienta.

Od WordPressa 6.6 problem widać w Narzędzia, Stan witryny. Gdy suma opcji ładowanych automatycznie przekroczy 800 KB, test zgłasza krytyczny problem „Autoloaded options could affect performance” (w polskim panelu: „Automatycznie wczytywane opcje mogą mieć wpływ na wydajność”) (ogłoszenie WordPress Core, 18.06.2024).

Tu jest pułapka, na którą wpada wiele poradników z gotowymi zapytaniami. Od wersji 6.6 kolumna autoload może mieć wartości on, off, auto, auto-on i auto-off, a starsze yes i no nadal działają. Zapytanie z warunkiem autoload = 'yes' pominie część opcji. Licz wszystkie wartości, które oznaczają ładowanie:

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

Największe opcje, czyli gdzie szukać winnego:

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

W WP-CLI łączny rozmiar sprawdzisz tak (dokumentacja wp option list):

wp option list --autoload=on --format=total_bytes
wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail -20

Nazwa opcji zwykle zdradza właściciela, bo wtyczki używają własnego przedrostka. Co z tym zrobić, piszę niżej w części o tym, czego nie ruszać bez planu.

Rewizje, kosz i autoszkice

SELECT post_type, post_status, COUNT(*) AS liczba
FROM wp_posts
GROUP BY post_type, post_status
ORDER BY liczba DESC;

Szukaj wierszy revision, auto-draft i statusu trash. Jeśli rewizji jest kilka razy więcej niż wpisów i stron, masz pierwszego kandydata do sprzątania.

Transienty

Transienty to tymczasowa pamięć wtyczek i motywów: wyniki zapytań do API, liczniki, gotowe fragmenty. Domyślnie lądują w wp_options, a WordPress usuwa wygasłe tylko od czasu do czasu, więc potrafią się gromadzić (dokumentacja Transients API).

SELECT COUNT(*) AS wiersze_transientow
FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

SELECT COUNT(*) AS wygasle_transienty
FROM wp_options
WHERE ( option_name LIKE '\_transient\_timeout\_%'
     OR option_name LIKE '\_site\_transient\_timeout\_%' )
  AND CAST( option_value AS UNSIGNED ) < UNIX_TIMESTAMP();

Pierwsza liczba to wiersze w tabeli, a nie liczba transientów: transient z czasem wygaśnięcia zajmuje dwa wiersze, wartość i osobny wiersz timeout. Druga liczba pokazuje, ile transientów już wygasło. Na zwykłej instalacji obejmuje to także transienty sieciowe (_site_transient_). Na multisite sieciowe leżą w osobnej tabeli wp_sitemeta, więc te zapytania pokażą tylko transienty jednej witryny.

Zwróć uwagę na ukośniki przed podkreślnikami. W SQL podkreślnik w LIKE oznacza „dowolny jeden znak”, więc wzorzec bez ukośników złapie także opcje, które transientami nie są. Przy SELECT to tylko zawyżony wynik. Przy DELETE to usunięte ustawienia wtyczki.

Ważne: jeśli strona ma zewnętrzny cache obiektowy (Redis albo Memcached), transienty trafiają do pamięci, a nie do bazy. Wtedy w wp_options znajdziesz ich mało albo wcale i ich czyszczenie w bazie nic nie da. Więcej o rodzajach cache piszę w poradniku o pamięci podręcznej w WordPressie.

Osierocone metadane

Metadane wpisów, których wpis już nie istnieje:

SELECT COUNT(*) AS osierocone_meta
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Kilkaset takich wierszy niczego nie zmienia. Dziesiątki tysięcy na sklepie to sygnał, że coś (import, stara wtyczka, ręczne kasowanie) usuwało wpisy z pominięciem WordPressa.

Co jeszcze siedzi w bazie poza tabelami

Ta rada nie dotyczy szybkości, ale skoro już jesteś w bazie, poświęć jej 10 sekund:

SHOW TRIGGERS;

Na typowej instalacji WordPressa wynik jest pusty. Kiedyś usuwaliśmy skutki włamania na sklepie WooCommerce. Wyczyściliśmy pliki, wp_options, zadania crona i Action Schedulera, zmieniliśmy hasła i klucze. Konto administratora i tak wracało. Przyczyną był trigger MySQL na tabeli komentarzy, który tworzył admina po dodaniu komentarza z określoną frazą. Skanery plików, WP-CLI i wtyczki bezpieczeństwa go nie widziały. Jeśli w wyniku zobaczysz coś, czego nie rozumiesz, nie kasuj tego sam, tylko potraktuj to jak incydent bezpieczeństwa.

Co możesz bezpiecznie czyścić

Element	Ryzyko	Jak
Stare rewizje	niskie, tracisz historię zmian	limit w wp-config.php i wtyczka albo czyszczenie po kopii
Wygasłe transienty	bardzo niskie	wp transient delete --expired
Spam i kosz komentarzy	niskie	panel komentarzy albo wtyczka
Wpisy w koszu	niskie, ale sprawdź, czy nikt ich nie potrzebuje	panel albo EMPTY_TRASH_DAYS
Autoszkice	niskie	wtyczka do czyszczenia

Rewizje i limit WP_POST_REVISIONS

WordPress domyślnie zapisuje nieograniczoną liczbę rewizji. Zamiast je wyłączać, ustaw limit w wp-config.php (dokumentacja wp-config.php):

<?php
// Limit rewizji na wpis. Wstaw nad linia "That's all, stop editing!".
define( 'WP_POST_REVISIONS', 5 );

Wyłączenie rewizji (false) odbiera Ci możliwość cofnięcia zmian, gdy ktoś nadpisze tekst. Limit to rozsądny kompromis. Przy kolejnym zapisie danego wpisu WordPress sam usuwa jego najstarsze nadmiarowe rewizje (wp_save_post_revision). Stare rewizje wpisów, których nikt już nie edytuje, zostaną, dopóki nie usuniesz ich wtyczką.

Wygasłe transienty

wp transient delete --expired

To najbezpieczniejsza operacja w całym tym wpisie. Usuwa tylko to, co i tak straciło ważność (dokumentacja wp transient delete). Transienty sieciowe usuwa osobno ta sama komenda z flagą --network, a na multisite każdą witrynę trzeba wskazać przez --url.

Wariant wp transient delete --all usuwa wszystkie transienty. Zwykle nic się nie psuje, bo dobrze napisana wtyczka odtworzy dane, ale zrób to po kopii i przetestuj kluczowe akcje. Strona może przez chwilę działać wolniej, bo wszystko liczy się od nowa. Na sklepie w szczycie sprzedaży lepiej tego nie robić.

Spam, kosz i autoszkice

Spam i kosz komentarzy wyczyścisz z panelu. Wpisy z kosza WordPress usuwa sam po 30 dniach. Ten okres zmienisz stałą EMPTY_TRASH_DAYS. Autoszkice najwygodniej usunąć wtyczką, o której piszę niżej.

Czego nie ruszać albo ruszać tylko z planem

Autoload - wyłącz zamiast kasować

Duża opcja z autoload nie zawsze jest śmieciem. Może to być konfiguracja aktywnej wtyczki, motywu albo buildera. Kolejność, którą polecam:

1. Ustal właściciela po przedrostku nazwy opcji.
2. Jeśli wtyczka jest usunięta, opcja jest pozostałością. Możesz ją usunąć po kopii.
3. Jeśli wtyczka jest aktywna, nie kasuj opcji. Sprawdź jej ustawienia (często duże opcje to logi albo statystyki, które da się wyłączyć) albo zapytaj autora wtyczki.
4. Wyłączenie autoload dla pojedynczej, dużej opcji jest mniej ryzykowne niż jej usunięcie, bo dane zostają. Rób to wtyczką albo WP-CLI, a nie ręcznym UPDATE, i testuj stronę od razu po zmianie.

Nowe duże opcje (powyżej 150 000 bajtów) WordPress od 6.6 sam zapisuje bez autoload, o ile wtyczka nie wymusi inaczej. Stare zostają, jak były.

Tabele po wtyczkach

Usunięcie wtyczki często zostawia jej tabele. Tabela osierocona to taka, której wtyczka naprawdę nie ma już na stronie. Zanim ją usuniesz:

• sprawdź, czy wtyczka nie jest tylko wyłączona (po ponownym włączeniu straciłbyś dane),
• sprawdź, czy to nie tabela innej wtyczki o podobnej nazwie,
• na multisite pamiętaj, że każda witryna ma własne tabele z innym prefiksem.

Nie usuwaj tabel tylko dlatego, że wtyczka do czyszczenia oznaczyła je jako „nieużywane”. Takie rozpoznanie bywa zgadywaniem po nazwie.

Indeksy

Indeksy przyspieszają wyszukiwanie w dużych tabelach, takich jak wp_postmeta w sklepie z tysiącami produktów. Poradniki z gotowymi CREATE INDEX bywają błędne: zdarzają się indeksy z warunkiem WHERE, których MySQL i MariaDB nie obsługują, albo indeksy dublujące te, które WordPress już ma.

Jeśli chcesz iść tą drogą, użyj sprawdzonej wtyczki, na przykład Index WP MySQL For Speed (wersja 1.6.0, ponad 50 tys. instalacji według katalogu WordPress.org, stan na 22.10.2026). Działa tylko z InnoDB, ma obsługę WP-CLI i pozwala cofnąć zmiany. Uwaga: dezaktywacja wtyczki nie usuwa dodanych kluczy, do tego służy narzędzie wtyczki albo wp index-mysql disable --all. Najpierw na kopii strony, potem na produkcji.

Sklep WooCommerce - Action Scheduler i HPOS

Action Scheduler

Action Scheduler to kolejka zadań w tle, z której korzysta WooCommerce i wiele wtyczek (subskrypcje, maile, synchronizacje). Dane trzyma w tabelach z przedrostkiem actionscheduler_ (FAQ Action Schedulera). Podgląd znajdziesz w WooCommerce, Status, Zaplanowane działania.

Stan kolejki w SQL:

SELECT status, COUNT(*) AS liczba
FROM wp_actionscheduler_actions
GROUP BY status;

Co warto wiedzieć, prosto z kodu biblioteki (ActionScheduler_QueueCleaner):

• wbudowane sprzątanie usuwa akcje starsze niż 31 dni, domyślnie o statusach complete i canceled,
• akcje failed mają osobny okres, 3 miesiące,
• okres zmienisz filtrem action_scheduler_retention_period.

Jeśli tabele rosną bez końca, zwykle przyczyną jest kolejka, która się nie uruchamia, a nie brak czyszczenia. Jak to zdiagnozować krok po kroku, opisałem we wpisie o Action Schedulerze w WooCommerce. Starsze zakończone akcje usuniesz bezpiecznie komendą (dokumentacja WP-CLI Action Schedulera):

wp action-scheduler clean

Domyślnie usuwa akcje canceled i complete starsze niż 31 dni, w paczkach po 20.

Czego nie robić: TRUNCATE na tabelach Action Schedulera. Zadania cykliczne planują swoje następne wykonanie dopiero w momencie wykonania, więc wyczyszczenie tabeli może je zatrzymać po cichu, bez komunikatu o błędzie. Dotyczy to też akcji pending, które czekają na wykonanie.

HPOS i stare dane zamówień

HPOS (High-Performance Order Storage) to osobne tabele zamówień w WooCommerce: wc_orders, wc_order_addresses, wc_order_operational_data i wc_orders_meta. Są stabilne od WooCommerce 8.2 i domyślne dla nowych sklepów (dokumentacja WooCommerce). Co daje HPOS i jak go włączyć, opisuję w osobnym wpisie o HPOS w WooCommerce.

Dla bazy ważne jest jedno. Sklep, który przeszedł na HPOS, często ma zamówienia w dwóch miejscach: w nowych tabelach i w starych wp_posts i wp_postmeta. Tak działa tryb zgodności, który synchronizuje oba zestawy.

Stan sprawdzisz komendą:

wp wc hpos status

Stare dane zamówień usuwa się komendą wp wc hpos cleanup (dla jednego zamówienia, zakresu albo all). Działa dopiero wtedy, gdy HPOS jest włączony, a tryb zgodności wyłączony, i sprawdza, czy dane w starych tabelach nie są nowsze (narzędzia CLI dla HPOS). Moja rada: nie spiesz się z tym. Tryb zgodności to Twoja droga powrotu, gdyby któraś wtyczka nie radziła sobie z HPOS. Wyłącz go dopiero, gdy sklep działa stabilnie, wtyczki są zgodne, a kopia jest świeża. I nie używaj --force, jeśli nie wiesz, dlaczego narzędzie odmawia.

OPTIMIZE TABLE i wp db optimize - co to robi naprawdę

wp db optimize

Ta komenda uruchamia mysqlcheck z opcją optymalizacji dla całej bazy (dokumentacja wp db optimize). Większość baz WordPressa działa na InnoDB, a dla InnoDB OPTIMIZE TABLE oznacza przebudowę tabeli i odświeżenie statystyk. MySQL wprost to komunikuje: „Table does not support optimize, doing recreate + analyze instead” (dokumentacja MySQL 8.4). To nie jest błąd.

Co z tego wynika w praktyce:

• Sens ma po dużym czyszczeniu, gdy usunąłeś dużą część danych z tabeli i chcesz odzyskać miejsce na dysku.
• Robienie tego co tydzień „profilaktycznie” niewiele daje. InnoDB celowo zostawia wolne miejsce na stronach danych.
• Przebudowa dużej tabeli trwa i na chwilę blokuje tabelę. Na sklepie uruchamiaj ją w spokojnych godzinach.

Wtyczki do czyszczenia bazy - WP-Optimize i Advanced Database Cleaner

Wtyczka to rozsądna droga dla kogoś bez SSH. Pod warunkiem, że rozumiesz, co zaznaczasz. Stan na 22.10.2026 według katalogu WordPress.org.

WP-Optimize (wersja 4.7.0, ponad 1 mln instalacji)

• Zalety: w wersji darmowej czyści rewizje, autoszkice, kosz, spam, optymalizuje tabele i pozwala ustawić harmonogram. Prosty interfejs z liczbą elementów przy każdej operacji.
• Ryzyka: harmonogram czyści „w ciemno”, także wtedy, gdy nikt nie patrzy na efekty. Obsługa WP-CLI, multisite i wybór pojedynczych tabel są w wersji Premium. Autor sam zaleca pełną kopię bazy przed pierwszym użyciem. Wtyczka ma też moduły cache i optymalizacji obrazów: jeśli używasz innej wtyczki cache, nie włączaj ich podwójnie.

Advanced Database Cleaner (wersja 4.2.0, ponad 100 tys. instalacji)

• Zalety: w wersji darmowej pokazuje duże opcje autoload i pozwala przełączać autoload, wykrywa zadania crona bez przypisanej akcji, ma harmonogram (do 5 zadań).
• Ryzyka: rozpoznawanie, do której wtyczki należy tabela lub opcja, oraz czyszczenie osieroconych tabel i opcji są w wersji Premium. Bez tego oceniasz właściciela sam. Autor pisze wprost, że kopia przed czyszczeniem jest obowiązkowa.

Zasada dla obu: pierwsze czyszczenie zrób ręcznie, operacja po operacji, z kopią i testem po każdym kroku. Harmonogram włącz dopiero dla operacji, które sprawdziłeś, czyli rewizji, spamu i wygasłych transientów.

Kiedy czyszczenie bazy nie przyspieszy strony

Baza bywa winna, ale rzadziej, niż sugerują wtyczki. Czyszczenie nie pomoże, gdy:

• strona jest wolna dla niezalogowanych, a cache strony działa. Odwiedzający dostaje wtedy gotowy HTML i baza prawie nie pracuje. Szukaj w obrazach, fontach i skryptach. Kolejność opisuję w poradniku jak przyspieszyć stronę na WordPressie.
• serwer jest za słaby albo przeciążony. Bardzo często największy skok szybkości daje zmiana hostingu, a nie sprzątanie.
• problemem jest jedno ciężkie zapytanie wtyczki. Usunięcie tysiąca rewizji go nie przyspieszy. Trzeba znaleźć to zapytanie.
• brakuje cache obiektowego. Na sklepie i w panelu Redis odciąża bazę bardziej niż jej czyszczenie. Przy wyborze hostingu sprawdzamy, czy go oferuje.

Czysta baza na pewno daje mniejsze i szybsze kopie oraz zwykle lżejszy panel. Obietnic typu „lepsze pozycje w Google po czyszczeniu bazy” nie składam, bo nie mam na to dowodu.

Jak my z tym pracujemy

Przegląd bazy to u nas stały punkt opieki nad stroną. Robimy go najczęściej z wtyczką Query Monitor, a często także własnym kodem, np. zapytaniami podobnymi do tych z tego wpisu.

Wchodzimy od pomiaru, nie od włączania opcji. Gdy strona zwolniła, a nic się nie wywala, debug log jest złym narzędziem (więcej o nim w poradniku o trybie debugowania WordPressa). Wtedy sięgamy po wtyczkę Query Monitor i przechodzimy stronę po stronie, bo winowajcą bywa baza danych albo kod.

Na sklepie WooCommerce problem zwykle nie leży tam, gdzie wskazują narzędzia do pomiaru szybkości. Siedzi na stronach koszyka i zamówienia oraz w samym dodaniu produktu do koszyka, czyli tam, gdzie cache strony nie działa. Dlatego zaczynamy od szukania powolnych zapytań do bazy właśnie tam, a dopiero potem od nadmiarowych skryptów i stylów.

Na wizytówce i blogu zwykle wystarczają podstawy. Jeśli strona jest wolna mimo tego, częściej winny jest sposób jej zbudowania (kilka builderów, wiele wtyczek z zewnętrznymi skryptami) albo serwer niż baza.

Po każdej zmianie, także po czyszczeniu bazy, klikamy ręcznie kluczowe akcje: dodanie do koszyka, otwarcie koszyka, usunięcie produktu, wysłanie formularza ze sprawdzeniem, czy dane doszły do panelu, złożenie zamówienia, popupy i rozwiązania zbudowane pod klienta. Każdą w trzech warunkach: jako zalogowany, niezalogowany i w oknie incognito. Różnica między nimi to najczęstsze miejsce, w którym chowa się awaria.

Kiedy nie u nas: gdy problemem jest serwer albo builder, żadne czyszczenie ani dodatkowa warstwa tego nie naprawi. Najpierw hosting i sposób zbudowania strony, potem reszta.

Podsumowanie

Optymalizacja bazy danych WordPress w bezpiecznej kolejności:

1. Kopia bazy poza serwerem i sprawdzony prefiks tabel.
2. Pomiar: rozmiar tabel, autoload (Stan witryny), rewizje, transienty, Action Scheduler.
3. Czyszczenie rzeczy bezpiecznych: wygasłe transienty, spam, kosz, autoszkice, stare rewizje z limitem.
4. Z planem: autoload (najpierw właściciel opcji), tabele po usuniętych wtyczkach, indeksy, wp action-scheduler clean, HPOS cleanup po wyłączeniu trybu zgodności.
5. wp db optimize po dużym czyszczeniu, w spokojnych godzinach.
6. Test kluczowych akcji jako zalogowany, niezalogowany i w incognito.

Jeśli nie chcesz ruszać bazy sklepu na produkcji samodzielnie, w ramach opieki nad stroną WordPress przegląd bazy jest stałym punktem: robię kopię, diagnozę i czyszczenie z testami po zmianie.

Najczęstsze pytania