Jak zoptymalizować bazę danych WordPress bez ciężkich wtyczek

Z doświadczenia wiem, że instalowanie kolejnej ciężkiej wtyczki tylko po to, by wyczyścić WordPressa, mija się z celem. Jeśli Twoja strona (na przykład po migracji z Divi 4 na Divi 5) odnotowuje wydłużone czasy zapytań, rozwiązanie leży w bezpośredniej pracy na bazie danych. Według dokumentacji technicznej MySQL, usuwanie zbędnych rekordów natywnymi komendami obniża obciążenie serwera odczuwalnie szybciej.

Dobra optymalizacja bazy danych WordPress nie wymaga płatnych narzędzi, ale wiedzy i ostrożności. Chcemy pozbyć się starych transjentów, zredukować wagę tabeli autoloaderów i wyrzucić rewizje. Wszystko to wykonamy z poziomu interfejsu phpMyAdmin lub poprzez terminal WP-CLI, zachowując 100% kontroli nad danymi.

Przed jakimikolwiek operacjami wykonaj pełną kopię zapasową bazy danych. W phpMyAdmin wykonaj eksport bazy (bez kompresji) i zaznacz opcję "Dodaj DROP TABLE" - zapisz to lokalnie na dysku. Usunięcie złego rekordu z wp_options oznacza natychmiastową awarię witryny.

Oczyszczanie tabeli wp_options z transjentów

Największym generatorem opóźnień na stronach z dużym ruchem jest tabela wp_options. Gromadzą się tu tzw. transjenty - wygasłe fragmenty pamięci tymczasowej z wtyczek czy starych motywów. Gdy uruchamiasz złożoną witrynę opartą na Divi, liczba nieaktualnych transjentów potrafi iść w tysiące.

Zamiast szukać wtyczki "Cleaner", wejdź w zakładkę SQL i użyj prostej komendy: DELETE FROM wp_options WHERE option_name LIKE '%_transient_%';. To błyskawicznie usunie stertę wirtualnych śmieci. Kolejnym krokiem powinno być namierzenie wpisów "autoload", przekraczających 500 KB, ponieważ ich ładowanie blokuje renderowanie strony.

Likwidacja rewizji postów w wp_posts

Jeśli posiadasz na blogu 4000 wpisów, system WordPress przy każdej edycji tekstu zapisuje jego kopię w bazie. W efekcie tabela wp_posts rozrasta się sztucznie, przechowując niepotrzebne rewizje i obniżając szybkość wyszukiwania. To właśnie one odpowiadają za spuchnięte, wielogigabajtowe zrzuty baz.

Uruchom zapytanie: DELETE FROM wp_posts WHERE post_type="revision", aby wykasować historię starszych wersji. Aby jednak zapobiec powrotowi problemu, edytuj główny plik wp-config.php na serwerze i dodaj linię kodu ograniczającą rewizje: define('WP_POST_REVISIONS', 5);. System zachowa tylko 5 ostatnich zmian.

Kasowanie osieroconych danych i śmieci (Orphaned Meta)

Gdy odinstalowujesz stare rozszerzenia (np. wtyczki Yoast z przeszłości lub stare szablony Divi 4), WordPress nie sprząta po nich w tabelach powiązanych. W wp_postmeta i wp_commentmeta lądują dziesiątki martwych połączeń, zwanych "osieroconymi metadanymi". Serwer wciąż je przetwarza, marnując zasoby obliczeniowe.

Trzeba to bezpiecznie wyczyścić za pomocą zapytań strukturalnych JOIN. Takie zapytanie sprawdza, czy identyfikator z tabeli postmeta posiada odpowiadający mu, żyjący wpis główny w tabeli wp_posts. Wszystkie wartości, które trafiają w próżnię, są trwale kasowane, odciążając wirtualny cache Litespeed.

Praktyczne operacje - co zrobić na koniec?

Skasowanie milionów wierszy z poziomu SQL zostawia tzw. wirtualne luki. Twoja waga fizyczna pliku bazy danych na dysku nie spadnie z automatu, ponieważ silnik MySQL wymaga przeprowadzenia procedury defragmentacji.

• Po zakończeniu operacji DELETE powróć do widoku tabel w phpMyAdmin, zaznacz wszystkie (opcja "Zaznacz wszystko" na dole ekranu) i z listy działań grupowych wybierz polecenie "Zoptymalizuj tabelę".
• Jeśli baza zgłasza usterki po ręcznych modyfikacjach, w tym samym oknie wybierz "Napraw tabelę", co ustabilizuje indeksy.

Taka bezwtyczkowa higiena, powtarzana raz na kwartał w połączeniu z regularnym opróżnianiem pamięci LiteSpeed Cache, zagwarantuje Ci najwyższą wydajność dla wymagających motywów i setek tysięcy wejść miesięcznie.