Tabela wp_options zawiera ustawienia WordPressa i wtyczek. Część opcji jest ładowana automatycznie przy praktycznie każdym żądaniu. To wygodne dla małych, często używanych ustawień, ale problematyczne, gdy plugin zapisze w autoloadzie duży cache, log, listę rekordów albo dane, które są potrzebne tylko w jednym miejscu. Wtedy każda podstrona płaci koszt za coś, czego nie używa.
Szybka odpowiedź
Stan witryny WordPressa ma test autoloaded options, a dokumentacja rdzenia wprost ostrzega, że ich nadmiar może pogarszać wydajność. Nie usuwaj jednak rekordów po samej nazwie. Najpierw zmierz łączny rozmiar, znajdź największe opcje, ustal do jakiego komponentu należą i sprawdź, czy są nadal używane.
Co oznacza autoload
Opcja oznaczona do automatycznego ładowania trafia do zestawu pobieranego wcześnie podczas obsługi żądania. Dla małego ustawienia używanego na wielu podstronach jest to dobre. Dla megabajtowego blobu potrzebnego raz na tydzień — nie. Decyzja powinna wynikać ze sposobu użycia danych, a nie z zasady „autoload zawsze zły”.
Stare wtyczki zostawiają śmieci
Odinstalowanie rozszerzenia nie zawsze usuwa jego ustawienia. Po latach wp_options może zawierać rekordy po pluginach, których nikt już nie pamięta. Zanim je skasujesz, zrób backup i potwierdź prefiks/nazwę w dokumentacji lub kodzie. Niektóre rekordy o dziwnej nazwie są krytyczne dla aktywnego systemu.
Duże transienty i cache
Transients mogą trafiać do tabeli opcji, jeśli nie ma persistent object cache. Normalnie mają mechanizm wygaśnięcia, ale błędny kod lub porzucone rekordy potrafią rosnąć. Nie zakładaj jednak, że „transient = można zawsze usunąć”; na produkcji najpierw sprawdź, co go tworzy i czy aplikacja potrafi bezpiecznie odtworzyć dane.
Zmiana flagi autoload
Nowoczesny WordPress ma mechanizmy pozwalające zmienić autoload bez ręcznego grzebania w surowej bazie. Dla własnego kodu ustawiaj autoload świadomie przy tworzeniu opcji. Dla cudzej wtyczki lepiej najpierw sprawdzić, czy producent nie zakłada automatycznego ładowania danego rekordu.
Redis nie naprawia złego modelu danych
Persistent object cache może ograniczyć liczbę odczytów z bazy, ale ogromny zestaw autoload nadal musi znaleźć się w pamięci procesu i cache. Redis jest optymalizacją, nie usprawiedliwieniem dla przechowywania niepotrzebnych megabajtów w danych ładowanych przy każdym żądaniu.
Jak potwierdzić, że naprawa naprawdę działa?
Po ograniczeniu autoloadu porównaj rozmiar zestawu w Site Health oraz TTFB kilku niecachowanych żądań. Następnie sprawdź ekrany i funkcje związane z wtyczką, której opcje zostały zmienione. Jeśli ustawienie jest potrzebne na każdym requestcie, przeniesienie go poza autoload może zwiększyć liczbę zapytań zamiast pomóc. Dlatego decyzję potwierdzaj pomiarem, nie samym spadkiem liczby kilobajtów.
Co obserwować po zmianie?
Zachowaj listę zmienionych opcji, ich poprzednią flagę i właściciela. Po aktualizacji wtyczki sprawdź, czy komponent nie odtworzył problematycznych rekordów. Jeżeli duży autoload wraca, przyczyną jest kod zapisujący dane, a ręczne czyszczenie będzie tylko cyklicznym leczeniem objawu.
Kiedy przekazać temat dalej?
Eskaluj, jeśli największe rekordy są serializowane, zaszyfrowane lub należą do krytycznej wtyczki bez dokumentacji. Usunięcie lub zmiana flagi bez testu może wywołać trudny do odtworzenia błąd ustawień na całej stronie.
Praktyczny scenariusz diagnostyczny
Praktyczny przypadek: tabela wp_options ma kilka megabajtów danych ładowanych automatycznie przy każdym żądaniu, a część pochodzi ze starej, usuniętej wtyczki. Najpierw zidentyfikuj największe wpisy i ich właścicieli. Nie kasuj opcji tylko dlatego, że nazwa wygląda obco — może być używana przez aktywny motyw lub integrację. Na kopii lub stagingu sprawdź, co się stanie po usunięciu/wyłączeniu autoload dla konkretnej opcji, a po zmianie porównaj rozmiar autoload i czas odpowiedzi. Jeżeli źródłem jest aktywna wtyczka generująca ogromne dane, aktualizacja lub poprawka w jej sposobie przechowywania jest lepsza niż cykliczne ręczne czyszczenie. Optymalizacja wp_options powinna być operacją kontrolowaną, bo błędne usunięcie może zmienić konfigurację całej witryny.
Bezpieczna kolejność działań
- Zrób backup bazy przed zmianą.
- Sprawdź Site Health i łączny rozmiar autoloaded options.
- Znajdź największe rekordy i ustal ich właściciela.
- Usuń wyłącznie dane osierocone albo zmień autoload po potwierdzeniu sposobu użycia.
- Wyczyść cache i wykonaj test funkcjonalny.
- Porównaj TTFB i wykorzystanie pamięci przed/po.
Czego nie robić
Nie uruchamiaj zapytania SQL kasującego „wszystkie duże opcje”. Rozmiar nie mówi, czy rekord jest zbędny. Nie zmieniaj także flag autoload dla kluczowych opcji WordPressa bez zrozumienia ich użycia.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli panel i frontend zwalniają mimo cache, możemy sprawdzić wp_options, rozmiar autoloadu i właścicieli największych rekordów, a następnie bezpiecznie uporządkować dane bez kasowania potrzebnych ustawień.
Źródła techniczne
Najczęściej zadawane pytania
Czy można usunąć wszystkie autoloaded options?
Nie. Wiele z nich jest potrzebnych WordPressowi i aktywnym wtyczkom.
Czy duża liczba rekordów zawsze oznacza problem?
Nie tylko liczba ma znaczenie. Ważny jest łączny rozmiar oraz to, jakie dane są ładowane przy każdym żądaniu.
Czy Site Health sprawdza autoload?
Tak. WordPress posiada test dotyczący automatycznie ładowanych opcji i ostrzega, gdy ich rozmiar staje się problemem.
Czy Redis rozwiązuje problem autoloadu?
Może ograniczyć część kosztu bazy, ale nie usuwa problemu nadmiernej ilości danych ładowanych do pamięci.