Optymalizacja bazy danych WordPress - kompletny poradnik

Baza danych to miejsce, w którym WordPress trzyma praktycznie wszystko: treść wpisów i podstron, komentarze, ustawienia motywu, konfiguracje wtyczek, dane użytkowników i metadane. Każde zapytanie do strony to seria odczytów z tej bazy – im więcej zbędnych rekordów, tym dłużej trwa złożenie strony do wyświetlenia.

Problem narasta po cichu. Strona, która na starcie ładuje się błyskawicznie, po roku aktualizacji wtyczek, edycji wpisów i akcji spamowych potrafi obciążać serwer dziesiątkami tysięcy niepotrzebnych wierszy. Najmocniej odczuwa to panel administracyjny i strony dynamiczne (sklep, wyszukiwarka), gdzie cache nie zawsze pomaga.

W praktyce rzadko chodzi o sam rozmiar bazy w megabajtach. Większy wpływ ma to, ile rekordów WordPress przeczesuje przy każdym żądaniu oraz czy tabele mają poukładaną strukturę. Dlatego optymalizacja to dwa osobne zadania: czyszczenie zbędnych danych i porządkowanie samych tabel.

Osobnym, rzadziej omawianym tematem są indeksy. Domyślne tabele WordPressa mają sensowne indeksy, ale rozbudowane wtyczki (zwłaszcza sklepowe) potrafią generować zapytania, których standardowy indeks nie obsługuje optymalnie. To diagnostyka dla zaawansowanych – najpierw warto wyczerpać tańsze kroki: czyszczenie, autoload i cache, bo to one dają największy zwrot przy najmniejszym ryzyku.

Cztery rodzaje danych odpowiadają za większość rozrostu bazy. Warto je rozpoznać, zanim cokolwiek usuniesz – każdy wymaga innego podejścia.

Rewizje wpisów to najczęstszy winowajca. WordPress przy każdym zapisie wpisu tworzy nowy wiersz typu revision. Wpis edytowany 40 razy zostawia 40 rewizji – przy kilkuset wpisach tabela wp_posts puchnie wielokrotnie ponad faktyczną treść.

Transienty to mechanizm tymczasowego cache. Wtyczki zapisują w wp_options odpowiedzi z API, wyniki zapytań czy feedy z datą wygaśnięcia. Problem w tym, że wygasłe transienty nie zawsze są automatycznie sprzątane i potrafią gromadzić się tysiącami.

Spam i kosz rosną proporcjonalnie do ruchu. Tysiące odrzuconych komentarzy i ich metadane zostają w bazie, dopóki ktoś ich świadomie nie usunie. To samo dotyczy wpisów i stron przeniesionych do kosza.

Backup całej bazy przed optymalizacją nie jest opcją, tylko warunkiem. Najgorszy scenariusz wygląda tak: wchodzisz do phpMyAdmin, usuwasz rekordy, które wyglądają na zbędne, a po chwili znika konfiguracja sklepu albo formularza. Z kopią cofniesz to w minutę, bez kopii tracisz dane.

Najszybciej zrobisz backup przez WP-CLI: `wp db export backup.sql`. Plik zapisuje się w katalogu strony i zawiera całą bazę. Jeśli nie masz dostępu do SSH, wyeksportuj bazę z phpMyAdmin (zakładka Eksport) lub użyj wtyczki backupowej, która zrzuca pełną bazę przed czyszczeniem.

Osobna zasada dotyczy ręcznego usuwania z wp_options. Nigdy nie kasuj rekordu, którego nie rozumiesz, tylko dlatego, że jest duży – część dużych opcji to legalne dane motywu lub buildera. Najpierw sprawdź nazwę opcji, dopiero potem decyduj.

Dla większości właścicieli stron wtyczka to najbezpieczniejsza droga – nie wymaga dotykania SQL. WP-Optimize jest najpopularniejszym wyborem, ale Advanced Database Cleaner daje większą kontrolę nad podglądem danych, a WP-Sweep korzysta z natywnych funkcji WordPressa zamiast surowych zapytań.

Po instalacji (Wtyczki → Dodaj nową → WP-Optimize → aktywuj) przejdź do WP-Optimize → Database. Zobaczysz listę operacji z licznikiem rekordów do wyczyszczenia przy każdej z nich:

• Clean all post revisions – usuwa rewizje wpisów
• Clean all auto-draft posts – kasuje porzucone autozapisy
• Clean all trashed posts – opróżnia kosz wpisów
• Remove spam and trashed comments – usuwa komentarze spam i z kosza
• Remove expired transient options – czyści wygasłe transienty
• Optimize database tables – porządkuje strukturę tabel

Zaznacz wybrane opcje i kliknij Run all selected optimizations. Najważniejsza różnica względem ręcznej pracy: WP-Optimize domyślnie usuwa tylko wygasłe transienty i pokazuje, ile rekordów zniknie, zanim wykonasz akcję.

Ustaw też harmonogram (Settings → Scheduled clean-up), na przykład raz w tygodniu, i ogranicz retencję rewizji do kilku ostatnich. Dzięki temu baza nie urośnie ponownie. Funkcje kompresji obrazów i cache w WP-Optimize traktuj jako dodatek – do czyszczenia bazy wystarczy zakładka Database.

Ręczna droga daje pełną kontrolę i jest szybsza na dużych bazach, ale wymaga ostrożności – tu nie ma okienka z potwierdzeniem. Najbezpieczniejsze jest WP-CLI, bo używa logiki WordPressa zamiast surowego SQL.

Usunięcie rewizji, wyczyszczenie transientów i optymalizacja tabel przez WP-CLI:

wp db export backup.sql
wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp transient delete --all
wp db optimize

Jeśli wolisz SQL (phpMyAdmin), te same czynności wyglądają tak. Pamiętaj o właściwym prefiksie tabel – domyślnie wp_, ale wiele instalacji ma własny:

DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_options WHERE option_name LIKE '%\_transient\_%';
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

Warto rozumieć różnicę: DELETE usuwa zbędne rekordy, a OPTIMIZE TABLE reorganizuje fizyczną strukturę tabeli i odzyskuje miejsce po skasowanych wierszach. To dwie różne operacje – samo kasowanie bez OPTIMIZE zostawia fragmentację.

Osobny temat to osierocone metadane. Po latach w wp_postmeta i wp_commentmeta zostają wpisy wskazujące na nieistniejące już wpisy czy komentarze. WP-Sweep i Advanced Database Cleaner potrafią je wykryć i usunąć bezpieczniej niż ręczne zapytania.

Zanim odpalisz jakiekolwiek SQL, sprawdź jeszcze jedną rzecz: prefiks tabel. Domyślnie to wp_, ale wiele instalacji ze względów bezpieczeństwa używa własnego (np. wpxy_). Polecenie z błędnym prefiksem albo nic nie zrobi, albo zadziała na niewłaściwych danych. Prefiks znajdziesz w wp-config.php przy zmiennej table_prefix.

Autoloaded options to dane, które WordPress ładuje przy każdym pojedynczym żądaniu strony – jeszcze zanim cokolwiek się wyświetli. To one są najczęstszą, niewidoczną przyczyną wolnej bazy, bo ich rozmiar mnoży się przez liczbę odsłon.

Sprawdź łączny rozmiar autoload jednym zapytaniem:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options WHERE autoload = 'yes';

Jako orientacyjny próg przyjmuje się około 1 MB. Wynik wyraźnie powyżej tej wartości oznacza, że przy każdym żądaniu serwer ładuje niepotrzebny balast. Żeby znaleźć konkretnych winowajców, wylistuj największe opcje:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;

Na liście często widać pozostałości po odinstalowanych wtyczkach – stare logi, cache, dane konfiguracyjne, które nikt już nie czyta. Takiej opcji nie musisz od razu kasować; bezpieczniej wyłączyć jej autoload:

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'nazwa_opcji';

Reguła praktyczna: jeśli rozpoznajesz wtyczkę i jest odinstalowana – opcję można usunąć; jeśli nie masz pewności – wyłącz autoload zamiast kasować. Do diagnostyki, co realnie obciąża bazę przy konkretnej podstronie, przydaje się wtyczka Query Monitor.

Sprzątanie bez prewencji to praca, którą będziesz powtarzać co miesiąc. Dwie zmiany w pliku wp-config.php zatrzymują główne źródło rozrostu, czyli rewizje i autozapisy.

Ogranicz liczbę rewizji na wpis i wydłuż interwał autozapisu:

// Maksymalnie 3 rewizje na wpis
define('WP_POST_REVISIONS', 3);

// Autozapis co 120 sekund (domyślnie 60)
define('AUTOSAVE_INTERVAL', 120);

Całkowite wyłączenie rewizji (`define('WP_POST_REVISIONS', false);`) jest możliwe, ale tego nie polecamy – rewizje ratują przy przypadkowej utracie treści. Limit 3-5 to rozsądny kompromis między bezpieczeństwem a wagą bazy.

Na stronach z dużym ruchem dynamicznym (sklep, wyszukiwarka) sam porządek w bazie czasem nie wystarczy. Jeśli WordPress wykonuje setki powtarzalnych zapytań, włącz object cache na Redis – odciąża bazę, zapamiętując wyniki zapytań w pamięci. To jednak osobny temat wydajnościowy, nie czyszczenie.

Dobry rytm to przegląd bazy raz na kwartał przy spokojnej stronie i po każdej większej zmianie – wymianie motywu, instalacji lub usunięciu wtyczek. Wtedy w bazie zostaje najwięcej pozostałości.

W naszych wdrożeniach najczęściej widzimy, że sama optymalizacja bazy daje odczuwalny skok tylko tam, gdzie baza była naprawdę zaniedbana – ogromne autoload, dziesiątki tysięcy rewizji, tabele bez sensownych indeksów. Na stronie utrzymywanej w porządku różnica po wyczyszczeniu rewizji bywa kosmetyczna.

Dlatego do każdego zlecenia podchodzimy diagnostycznie: najpierw mierzymy rozmiar autoload i liczbę zapytań na podstronę (Query Monitor), dopiero potem czyścimy. Częsty błąd, który naprawiamy po innych wykonawcach, to agresywne kasowanie z wp_options bez backupu – kilka razy odtwarzaliśmy w ten sposób utracone ustawienia sklepu.

Jeśli wolisz, żeby porządek w bazie i wydajność strony ogarnął ktoś, kto robi to na co dzień, sprawdź naszą ofertę WordPress albo szerszą ofertę stron internetowych. Możesz też od razu umówić bezpłatną konsultację – przejrzymy Twoją bazę i powiemy, czy problem leży w niej, czy gdzie indziej.