Jak zoptymalizować bazę danych WordPress?

Baza danych WordPress jest jak zaplecze Twojej strony. Przechowuje wpisy, strony, ustawienia, rewizje, komentarze, dane użytkowników, opcje wtyczek, transient, metadane, a w WooCommerce także produkty, zamówienia, koszyki i sesje. Gdy baza jest uporządkowana, WordPress ma mniej zbędnych rekordów do przetworzenia, backupy są lżejsze, a panel administracyjny działa dużo bardziej przewidywalnie.

Optymalizacja nie polega jednak na kliknięciu jednego przycisku. Bezpieczny proces zaczyna się od kopii zapasowej, pomiaru rozmiaru tabel i analizy, które dane naprawdę można usunąć. Dopiero później przychodzi czas na czyszczenie rewizji, autoloaded options, transientów, logów i tabel pozostawionych przez nieaktywne wtyczki.

W tym poradniku znajdziesz praktyczne komendy WP-CLI, zapytania SQL i fragmenty konfiguracji wp-config.php. Pokażę Ci też, kiedy lepiej nie usuwać danych ręcznie, jak sprawdzić autoload w wp_options, jak wykorzystać Redis i dlaczego dobry hosting WordPress ma duże znaczenie dla wydajności bazy.

Zacznij od backupu i pomiaru bazy

Najgorszy scenariusz wygląda tak. Wchodzisz do phpMyAdmin, widzisz dużą tabelę, usuwasz rekordy, a po chwili okazuje się, że zniknęły ustawienia sklepu, formularzy albo buildera. Dlatego pierwsza zasada brzmi prosto. Nie optymalizuj bazy produkcyjnej bez kopii zapasowej.

Jeśli korzystasz z cyber_Folks, dostęp do phpMyAdmin znajdziesz w panelu hostingu, a dane połączenia WordPress przechowuje w pliku wp-config.php. W pomocy cyber_Folks znajdziesz instrukcję logowania do bazy przez phpMyAdmin oraz opis, gdzie CMS-y przechowują dane bazodanowe. W WordPressie są to wartości DB_NAME, DB_USER, DB_PASSWORD i DB_HOST.

Jeżeli masz SSH i WP-CLI, najpierw wykonaj eksport bazy. Nazwa pliku z datą ułatwi późniejsze odtworzenie właściwej wersji.

# Przejdź do katalogu WordPressa
cd ~/domains/twojadomena.pl/public_html

# Eksport bazy przez WP-CLI
wp db export backup-before-db-cleanup-$(date +%F-%H%M).sql

# Kontrola, czy plik rzeczywiście powstał
ls -lh backup-before-db-cleanup-*.sql

Jeśli nie masz WP-CLI, wykonaj eksport z phpMyAdmin albo panelu hostingu. Przy większych bazach wygodniejszy bywa mysqldump, ale wymaga poprawnych danych dostępowych i dostępu do powłoki.

# Przykład mysqldump. Podmień dane na własne.
mysqldump -u DB_USER -p DB_NAME > backup-before-db-cleanup.sql

Po kopii sprawdź rozmiar bazy i największe tabele. To pozwala odróżnić realny problem od zwykłego wrażenia, że baza jest duża.

# Rozmiar bazy przez WP-CLI
wp db size --human-readable

# Lista tabel z rozmiarem
wp db size --tables --human-readable

Ten sam pomiar możesz wykonać w SQL. Pamiętaj, że w WordPressie prefiks tabel nie zawsze brzmi wp_. Sprawdź go w wp-config.php w zmiennej $table_prefix.

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;

Ogranicz rewizje, autozapisy i kosz

Rewizje są przydatne, bo pozwalają wrócić do wcześniejszej wersji wpisu. WordPress przechowuje je w tabeli wpisów jako specjalny typ treści revision. Problem pojawia się wtedy, gdy aktywny blog lub serwis firmowy przez lata zapisuje każdą zmianę bez limitu.

Zacznij od policzenia rewizji. Komenda poniżej niczego nie usuwa.

# Liczba rewizji w bazie
wp post list --post_type=revision --format=count

Możesz też sprawdzić to przez SQL.

SELECT COUNT(*) AS liczba_rewizji
FROM wp_posts
WHERE post_type = 'revision';

Jeśli chcesz ograniczyć przyrost rewizji w przyszłości, dodaj limit w pliku wp-config.php. Wstaw go nad komentarzem /* That's all, stop editing! Happy publishing. */.

// Przechowuj maksymalnie 5 rewizji na wpis lub stronę.
define( 'WP_POST_REVISIONS', 5 );

// Opróżniaj kosz po 14 dniach.
define( 'EMPTY_TRASH_DAYS', 14 );

Nie polecam całkowitego wyłączania rewizji na stronach, gdzie nad treściami pracuje kilka osób. Lepiej zostawić rozsądny limit. Jeżeli chcesz usunąć stare rewizje, najpierw zrób podgląd.

# Podgląd przykładowych rewizji
wp post list \
  --post_type=revision \
  --fields=ID,post_parent,post_date,post_title \
  --format=table \
  --posts_per_page=20

Dopiero po sprawdzeniu możesz usuwać. Przy dużej liczbie rewizji bezpieczniej robić to partiami.

# Usuń rewizje starsze niż 90 dni. Przetestuj najpierw na kopii strony.
wp post list \
  --post_type=revision \
  --date_query_column=post_date \
  --before='90 days ago' \
  --format=ids | xargs -r wp post delete --force

W SQL zawsze zaczynaj od SELECT. Dopiero gdy wynik jest zgodny z oczekiwaniem, wykonuj DELETE.

-- 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;

-- Wykonuj tylko po backupie i weryfikacji SELECT.
DELETE FROM wp_posts
WHERE post_type = 'revision'
  AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

Sprawdź autoloaded options w wp_options

Tabela wp_options potrafi mocno wpływać na czas odpowiedzi WordPressa. Przechowuje ustawienia WordPressa, motywów i wtyczek. Szczególnie ważne są opcje ładowane automatycznie, czyli autoloaded options. WordPress pobiera je przy każdym żądaniu, więc duże lub niepotrzebne rekordy mogą spowalniać zarówno frontend, jak i panel administratora.

Od WordPress 6.6 autoload jest bardziej szczegółowy niż kiedyś. Oprócz historycznych wartości yes i no pojawiają się też między innymi on, off, auto, auto-on i auto-off. Dlatego aktualne zapytania diagnostyczne powinny sprawdzać więcej niż samo autoload = 'yes'.

Najpierw zobacz łączny rozmiar opcji ładowanych automatycznie.

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');

Następnie znajdź największe rekordy. Ta komenda niczego nie usuwa, tylko pokazuje kandydatów do analizy.

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;

Jeżeli zobaczysz rekordy po starej wtyczce, której nie ma już na stronie, nie usuwaj ich od razu. Sprawdź nazwę opcji, dokumentację wtyczki i zrób test na kopii. Często bezpieczniejszym pierwszym ruchem jest wyłączenie autoload, a nie kasowanie wartości.

-- Przykład. Zmień nazwę opcji na konkretną, sprawdzoną pozycję.
-- Najpierw podgląd.
SELECT option_id, option_name, autoload, LENGTH(option_value) AS bajty
FROM wp_options
WHERE option_name = 'nazwa_duzej_opcji';

-- Potem ewentualna zmiana autoload.
-- W starszych instalacjach często używa się 'no'.
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'nazwa_duzej_opcji';

W nowych projektach i własnym kodzie ustawiaj autoload świadomie. Opcje potrzebne na każdej podstronie mogą być autoloadowane. Opcje używane tylko w panelu, raporcie albo integracji nie powinny ładować się przy każdym wejściu użytkownika.

// Opcja potrzebna na każdej podstronie.
add_option( 'moja_wtyczka_global_config', $config, '', true );

// Opcja używana rzadko, np. tylko w panelu ustawień.
add_option( 'moja_wtyczka_raport_importu', $report, '', false );

// Aktualizacja z jawną decyzją o autoload.
update_option( 'moja_wtyczka_raport_importu', $report, false );

Wyczyść transienty, cache i dane tymczasowe

Transienty są przeznaczone do przechowywania danych tymczasowych. Wtyczki używają ich na przykład do cache’owania odpowiedzi API, wyników zapytań, feedów, fragmentów konfiguracji albo danych administracyjnych. Z czasem w bazie mogą zostać wygasłe transienty, które nie wnoszą już żadnej wartości.

Najbezpieczniej zacząć od WP-CLI. Poniższe komendy są czytelniejsze niż ręczne kasowanie rekordów w wp_options.

# Usuń wygasłe transienty.
wp transient delete --expired

# Usuń wszystkie transienty. Używaj ostrożnie, najlepiej poza szczytem ruchu.
wp transient delete --all

Jeżeli chcesz tylko zobaczyć skalę problemu, użyj SQL. Dla transientów WordPress zapisuje zwykle pary rekordów: wartość oraz timeout.

SELECT COUNT(*) AS liczba_transientow
FROM wp_options
WHERE option_name LIKE '_transient_%'
   OR option_name LIKE '_site_transient_%';

Podgląd wygasłych transientów możesz zrobić tak:

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;

Ręczne usuwanie transientów przez SQL jest możliwe, ale łatwo pominąć powiązany rekord wartości albo usunąć zbyt szeroki zakres. Dlatego w codziennej pracy lepiej używać WP-CLI lub sprawdzonej wtyczki, która pokazuje podgląd danych. Jednym z narzędzi do takiego porządkowania jest Advanced Database Cleaner, który obsługuje między innymi rewizje, auto-drafty, spam, wygasłe transienty i metadane.

Uporządkuj postmeta, commentmeta i usermeta

Tabele z metadanymi są częstym źródłem problemów, bo każda wtyczka może dopisywać własne informacje do wpisów, produktów, komentarzy i użytkowników. Najbardziej znana jest tabela wp_postmeta. W WooCommerce potrafi być jedną z największych tabel w całej bazie.

Nie usuwaj metadanych tylko dlatego, że mają dużo rekordów. Najpierw sprawdź, które klucze występują najczęściej.

SELECT
  meta_key,
  COUNT(*) AS liczba_rekordow,
  ROUND(SUM(LENGTH(meta_value)) / 1024 / 1024, 2) AS rozmiar_mb
FROM wp_postmeta
GROUP BY meta_key
ORDER BY liczba_rekordow DESC
LIMIT 30;

Osierocone rekordy w wp_postmeta to metadane, których wpis nadrzędny już nie istnieje. Najpierw wykonaj podgląd.

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;

Jeśli wynik jest jednoznaczny, po backupie możesz usunąć osierocone rekordy.

DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Analogicznie sprawdzisz osierocone metadane komentarzy i użytkowników.

-- Osierocone commentmeta
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 usermeta
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;

Przy WooCommerce zachowaj szczególną ostrożność. Produkty, warianty, zamówienia i ustawienia płatności korzystają z wielu rekordów meta. Jeżeli nie masz pewności, czy klucz jest zbędny, nie usuwaj go ręcznie na produkcji.

Znajdź logi, tabele po wtyczkach i zadania cron

Po odinstalowaniu wtyczki w bazie często zostają tabele, opcje, logi lub zadania cron. Nie zawsze jest to błąd. Czasem wtyczka celowo zostawia dane, aby po ponownej instalacji można było wrócić do poprzedniej konfiguracji. Problem zaczyna się wtedy, gdy nieużywane dane rosną dalej albo zajmują setki megabajtów.

Zacznij od listy tabel, które nie pasują do standardowych tabel WordPressa. Prefiks wp_ podmień na własny.

SHOW TABLES LIKE 'wp_%';

W WP-CLI szybciej sprawdzisz tabele i rozmiary tak:

# Wszystkie tabele WordPressa
wp db tables

# Tabele z rozmiarem
wp db size --tables --human-readable

Warto też przejrzeć zadania cron, szczególnie jeśli baza szybko puchnie po importach, synchronizacjach lub skanach bezpieczeństwa.

# Lista zadań cron
wp cron event list

# Szczegóły konkretnego hooka
wp cron event list --fields=hook,next_run,recurrence

Jeżeli w bazie widzisz duże tabele logów, sprawdź ustawienia retencji w konkretnej wtyczce. W wielu narzędziach da się ustawić przechowywanie logów przez 7, 14 lub 30 dni. To lepsze niż ręczne kasowanie tabel, bo nie łamie logiki wtyczki.

Do debugowania ciężkich zapytań przyda się Query Monitor. Pokazuje zapytania do bazy, błędy PHP, hooki, akcje, zapytania HTTP API i pozwala zawęzić źródło problemu do wtyczki, motywu lub funkcji.

# Szybka diagnostyka aktywnych wtyczek
wp plugin list --status=active

# Wyłącz testowo wtyczkę na środowisku staging
wp plugin deactivate nazwa-wtyczki

# Po teście włącz ponownie
wp plugin activate nazwa-wtyczki

Optymalizuj tabele przez WP-CLI lub SQL

Usuwanie danych i optymalizacja tabel to dwie różne rzeczy. Czyszczenie usuwa zbędne rekordy. Optymalizacja tabel pomaga uporządkować strukturę i odzyskać niewykorzystane miejsce po wielu operacjach zapisu i usuwania. Najpierw sprzątaj, potem optymalizuj.

Najprostsza komenda WP-CLI wygląda tak:

wp db optimize

WP-CLI korzysta z danych bazy zapisanych w wp-config.php. Jeżeli chcesz sprawdzić bazę przed optymalizacją, użyj:

wp db check

W MySQL lub MariaDB możesz użyć OPTIMIZE TABLE dla wybranych tabel. Nie wykonuj tego w ciemno na największych tabelach w godzinach szczytu, szczególnie przy sklepie lub serwisie z dużym ruchem.

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

Jeżeli analizujesz wolne zapytanie, użyj EXPLAIN. To pomaga sprawdzić, czy baza korzysta z indeksów, czy skanuje dużą liczbę rekordów.

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';

Nie dodawaj indeksów na produkcji bez analizy. Indeks może przyspieszyć jedno zapytanie, ale zwiększa koszt zapisu i rozmiar tabeli. Przy WooCommerce, katalogach i własnych typach treści lepiej najpierw sprawdzić, czy problem nie wynika z błędnego zapytania, braku cache albo nadmiaru meta query.

Włącz Redis i object cache, gdy baza dostaje za dużo zapytań

Nawet dobrze oczyszczona baza może być przeciążona, jeśli WordPress wykonuje zbyt wiele powtarzalnych zapytań. Tu pomaga cache obiektowy. Domyślny Object Cache w WordPressie działa tylko w trakcie pojedynczego żądania. Aby dane były przechowywane między kolejnymi odsłonami, potrzebujesz persistent object cache, na przykład Redis.

Redis przechowuje dane w pamięci RAM, dzięki czemu WordPress może szybciej sięgać po często wykorzystywane wyniki i ograniczać liczbę operacji na bazie. Na hostingu WordPress cyber_Folks Redis jest częścią środowiska, obok LiteSpeed Cache, NVMe, HTTP/3 i dostępu SSH. Instrukcja cyber_Folks opisuje konfigurację Redisa między innymi przez LS Cache oraz plugin Redis Object Cache.

Przykładowa konfiguracja dla wtyczki Redis Object Cache w wp-config.php może wyglądać tak. Dane hosta, portu i hasła pobierz z panelu usługi.

// Konfiguracja Redis. Wartości przykładowe.
define( 'WP_REDIS_HOST', 'redis3.cyber-folks.pl' );
define( 'WP_REDIS_PORT', 12345 );
define( 'WP_REDIS_PASSWORD', 'tu_wstaw_haslo' );

// Osobny prefiks zmniejsza ryzyko kolizji między instalacjami.
define( 'WP_REDIS_PREFIX', 'twojadomena_prod_' );

Po instalacji wtyczki sprawdź status przez WP-CLI.

# Włącz drop-in object-cache.php
wp redis enable

# Sprawdź status połączenia
wp redis status

# Wyczyść cache obiektowy
wp redis flush

Jeśli korzystasz z LiteSpeed Cache i Redis obsługujesz przez LS Cache, przydatne są też komendy czyszczenia cache.

# Wyczyść cache obiektowy WordPressa
wp cache flush

# W środowisku z LS Cache możesz użyć również:
wp litespeed-purge object

Redis nie zastępuje porządku w bazie. Jeśli w wp_options leżą wielomegabajtowe autoloaded options, a w wp_postmeta są osierocone rekordy, cache pomoże tylko częściowo. Najlepszy efekt daje połączenie czystej bazy, poprawnych zapytań, cache strony i cache obiektowego.

Procedura optymalizacji WordPress krok po kroku

Jeżeli chcesz działać metodycznie, użyj poniższej kolejności. Dzięki temu nie mieszasz diagnostyki z kasowaniem danych i łatwiej cofniesz zmianę, jeśli coś pójdzie nie tak.

• Wykonaj backup plików i bazy.
• Sprawdź rozmiar całej bazy i największych tabel.
• Policz rewizje, auto-drafty, spam, kosz i transienty.
• Sprawdź łączny rozmiar autoloaded options.
• Zidentyfikuj największe rekordy w wp_options.
• Wyczyść dane niskiego ryzyka, najlepiej przez WP-CLI lub sprawdzoną wtyczkę.
• Przejrzyj metadane i osierocone rekordy.
• Sprawdź logi, zadania cron i tabele po nieaktywnych wtyczkach.
• Po czyszczeniu wykonaj wp db optimize.
• Przetestuj frontend, panel, formularze, koszyk i checkout.
• Włącz lub sprawdź cache obiektowy Redis.
• Ustaw limity, aby baza nie rosła bez kontroli.

Na koniec zapisz wyniki. Prosty dziennik techniczny wystarczy, aby po miesiącu wiedzieć, czy problem wraca.

# Przykładowy mini raport po optymalizacji
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

Jeżeli po kilku tygodniach ta sama tabela znowu rośnie bardzo szybko, problemem nie jest sama baza, tylko mechanizm, który ją zapełnia. Wtedy wróć do diagnostyki wtyczek, cronów, importów i ciężkich zapytań.

Wtyczki, które pomogą zoptymalizować bazę WordPress

Jeżeli nie chcesz pracować bezpośrednio w SQL albo WP-CLI, część opisanych działań możesz wykonać przez sprawdzone wtyczki. To dobre rozwiązanie dla właściciela strony, który chce wyczyścić rewizje, autozapisy, spam, kosz, wygasłe transienty, osierocone metadane i zoptymalizować tabele bez ręcznego pisania zapytań. Nadal obowiązuje jednak ta sama zasada: najpierw backup, potem podgląd danych, a dopiero na końcu czyszczenie.

Nie instaluj kilku wtyczek czyszczących bazę jednocześnie. Wybierz jedno główne narzędzie do porządkowania danych, a diagnostykę i cache potraktuj jako osobne warstwy. Dzięki temu łatwiej kontrolować, co zostało usunięte, kiedy wykonano optymalizację i czy po zmianie strona, panel, formularze oraz koszyk działają poprawnie.

Advanced Database Cleaner. Dla kontroli i podglądu danych

Jeżeli chcesz, aby optymalizacja bazy dawała trwały efekt, połącz ją z dobrym środowiskiem serwerowym. Hosting WordPress daje dostęp do rozwiązań ważnych dla wydajności WordPressa, takich jak LiteSpeed Cache, Redis, NVMe, HTTP/3, SSH i phpMyAdmin. To dobry fundament dla strony, która ma szybko działać, łatwo się utrzymywać i stabilnie rosnąć.

Najbezpieczniejszy scenariusz wygląda tak: najpierw sprawdzasz podgląd rekordów, ustawiasz zasadę zachowania danych z ostatnich dni, wykonujesz czyszczenie małymi partiami, a po każdym kroku testujesz stronę. Funkcje związane z osieroconymi tabelami, opcjami, zadaniami cron i bardziej zaawansowaną automatyzacją mogą zależeć od wersji wtyczki, dlatego przed większym porządkiem sprawdź, które moduły są dostępne w Twojej instalacji.

WP-Optimize. Gdy chcesz połączyć bazę, cache i obrazy

WP-Optimize będzie dobrym wyborem, gdy chcesz mieć w jednym panelu czyszczenie bazy, cache strony, kompresję obrazów i minifikację plików. W kontekście bazy WordPress wtyczka pozwala usuwać między innymi rewizje, auto-drafty, wpisy z kosza, spam, komentarze w koszu oraz wykonywać optymalizację tabel. Przydatna jest także możliwość ustawienia harmonogramu cyklicznych porządków.

To rozwiązanie ma sens na prostszych stronach firmowych, blogach i serwisach, w których chcesz utrzymać porządek bez oddzielnego narzędzia do każdego obszaru wydajności. Jeżeli korzystasz już z innej wtyczki cache, na przykład LiteSpeed Cache, nie włączaj równolegle dwóch mechanizmów cache strony bez testów. W takiej sytuacji w WP-Optimize możesz skupić się wyłącznie na funkcjach bazodanowych, a cache pozostawić narzędziu dopasowanemu do serwera.

WP-Sweep. Dla prostego sprzątania bez nadmiaru opcji

WP-Sweep sprawdzi się wtedy, gdy potrzebujesz prostszego narzędzia do usunięcia typowych śmieci z bazy. Wtyczka obsługuje rewizje, auto-drafty, usunięte i spamowe komentarze, osierocone metadane wpisów, komentarzy, użytkowników i taksonomii, zduplikowane metadane, transienty oraz optymalizację tabel. Ważną zaletą jest to, że w wielu miejscach korzysta z natywnych funkcji WordPressa zamiast wykonywać bezpośrednie zapytania usuwające.

W praktyce WP-Sweep warto potraktować jako narzędzie do okresowego, ręcznego sprzątania. Najpierw wykonaj backup, potem przejdź sekcja po sekcji i nie klikaj czyszczenia wszystkiego naraz, jeśli strona ma WooCommerce, rozbudowane formularze, katalog produktów, wielojęzyczność albo wiele własnych typów treści. Przy bardziej skomplikowanych instalacjach lepiej testować każdy typ danych osobno na kopii strony.

Query Monitor. Do sprawdzenia, co obciąża bazę

Czyszczenie danych nie zawsze rozwiązuje problem. Jeśli baza po optymalizacji dalej działa wolno, potrzebujesz diagnozy zapytań. Query Monitor pomaga sprawdzić, które zapytania SQL wykonuje WordPress, jaka wtyczka lub motyw je wywołuje, czy pojawiają się błędy PHP, wolne hooki albo problematyczne zapytania HTTP API. To narzędzie nie sprząta bazy za Ciebie, ale wskazuje źródło obciążenia.

Użyj go szczególnie wtedy, gdy największy problem nie wynika z liczby rewizji czy transientów, tylko z konkretnej wtyczki, importu, filtra produktów, wyszukiwarki, buildera albo zapytania typu meta_query. Po takim teście możesz zdecydować, czy wystarczy czyszczenie danych, czy potrzebna jest zmiana konfiguracji wtyczki, poprawa kodu, indeks, cache obiektowy albo mocniejsze środowisko serwerowe.

Redis Object Cache. Gdy problemem są powtarzalne zapytania

Redis Object Cache nie usuwa zbędnych rekordów z bazy, ale pomaga ograniczyć liczbę powtarzalnych zapytań do MySQL lub MariaDB. To szczególnie ważne przy dynamicznych stronach, WooCommerce, rozbudowanych panelach administracyjnych i serwisach, w których wiele danych jest pobieranych wielokrotnie w krótkim czasie. Wtyczka wymaga jednak dostępnego serwera Redis i poprawnej konfiguracji po stronie hostingu.

Jeżeli korzystasz z hostingu WordPress, sprawdź w panelu usługi dane dostępowe do Redis i skonfiguruj wtyczkę zgodnie z parametrami środowiska. Cache obiektowy najlepiej wdrażać po podstawowym sprzątaniu bazy. W przeciwnym razie Redis będzie łagodził skutki problemu, ale nie usunie przyczyny, czyli nadmiaru autoloaded options, osieroconych metadanych, logów lub źle zaprojektowanych zapytań.

Jak wybrać wtyczkę do optymalizacji bazy?

• Chcesz dokładnego podglądu i większej kontroli? Zacznij od Advanced Database Cleaner.
• Chcesz prostego narzędzia do okresowego sprzątania? Sprawdź WP-Sweep.
• Chcesz połączyć czyszczenie bazy z cache i optymalizacją obrazów? Rozważ WP-Optimize, ale uważaj na dublowanie funkcji cache.
• Nie wiesz, która wtyczka lub motyw generuje wolne zapytania? Użyj Query Monitor.
• Baza jest czysta, ale WordPress nadal wykonuje dużo powtarzalnych zapytań? Włącz Redis Object Cache, jeśli Twoje środowisko go obsługuje.

Najlepszy efekt daje połączenie kilku warstw, ale bez chaosu w panelu WordPressa: jedna wtyczka do czyszczenia bazy, jedno narzędzie do diagnostyki, jeden mechanizm cache strony i jeden cache obiektowy, jeśli jest potrzebny. Po każdej większej zmianie porównaj rozmiar bazy, czas działania panelu, liczbę zapytań i działanie krytycznych funkcji strony. Dopiero wtedy uznasz optymalizację za zakończoną.

Najpierw bezpieczeństwo, później szybkość

Dobra optymalizacja bazy WordPress zaczyna się od kopii zapasowej i pomiaru. Dopiero później przychodzi czas na usuwanie rewizji, transientów, spamu, osieroconych metadanych, logów i zbędnych opcji. Przy każdym kroku trzymaj się prostej zasady: najpierw podgląd danych, potem decyzja, a dopiero na końcu czyszczenie.

Najwięcej uwagi poświęć tabeli wp_options, autoloaded options i dużym tabelom meta. To miejsca, w których często odkłada się techniczny dług po wtyczkach, builderach, integracjach, importach i starszych wersjach strony. Uporządkowana baza ułatwia backup, przyspiesza panel administracyjny i zmniejsza koszt zapytań wykonywanych przez WordPressa.

Nie wszystko musisz robić ręcznie. Wtyczki takie jak Advanced Database Cleaner, WP-Optimize czy WP-Sweep mogą pomóc w bezpieczniejszym usuwaniu rewizji, auto-draftów, transientów, spamu i osieroconych metadanych. Traktuj je jednak jak narzędzia do kontrolowanej pracy, a nie magiczny przycisk do naprawy całej strony.

Jeżeli po czyszczeniu baza nadal spowalnia stronę, przejdź do diagnostyki. Query Monitor pomoże sprawdzić, która wtyczka, motyw lub funkcja generuje ciężkie zapytania. Z kolei Redis Object Cache może ograniczyć liczbę powtarzalnych zapytań do bazy, jeśli Twoje środowisko obsługuje Redis.

Najlepszy efekt daje połączenie kilku działań: backupu, pomiaru, czyszczenia danych niskiego ryzyka, optymalizacji tabel, sprawdzenia zapytań i dobrze skonfigurowanego cache. Jeżeli Twoja strona działa na hostingu WordPress, łatwiej utrzymać stabilność bazy, cache i panelu administracyjnego przy codziennej pracy nad serwisem.