Autoload w WordPressie: wartości, zapytania i zużycie pamięci

WordPress ładuje często potrzebne opcje razem do zestawu alloptions. Kolumna autoload określa domyślny skład tego zestawu. Od WordPressa 6.6 sprawdzanie wyłącznie wartości yes nie wystarcza: automatyczne ładowanie mogą oznaczać także inne wartości.

Co dzieje się podczas ładowania

Opcje witryny zwykle znajdują się w odpowiedniej tabeli opcji. Przy tworzeniu alloptions WordPress najpierw sprawdza pamięć podręczną obiektów. Zapytanie do bazy następuje dopiero przy braku odpowiedniego trafienia. Pamięć podręczna całych stron może nawet dostarczyć stronę bez pełnego uruchamiania WordPressa. Pliki statyczne i niezależne skrypty PHP nie ładują automatycznie opcji WordPressa.

Autoload ogranicza liczbę osobnych zapytań, ale obejmuje również wartości niepotrzebne w bieżącym żądaniu. Opcje bez autoload pozostają dostępne przez get_option() i również mogą trafiać do pamięci podręcznej. Brak automatycznego ładowania nie oznacza usunięcia ani koniecznie wolnego odczytu.

Które wartości się liczą

• yes i no: starsze, nadal obsługiwane oznaczenia.
• on i off: jawnie włączone lub wyłączone autoload.
• auto-on i auto-off: wynik automatycznej decyzji.
• auto: brak jednoznacznej automatycznej decyzji; domyślnie również ładowane.

wp_autoload_values_to_autoload() domyślnie zwraca yes, on, auto-on i auto. Filtr o tej samej nazwie może usuwać wartości z listy. Lista obowiązująca podczas działania może więc być krótsza. Aktualizacja nie usuwa automatycznie wszystkich istniejących oznaczeń yes.

Kontrola SQL tylko do odczytu

Poniższe zapytanie podaje liczbę opcji i bajty zapisanych wartości dla domyślnej listy. wp_options należy zastąpić rzeczywistą nazwą tabeli, szczególnie przy innym prefiksie lub instalacji Multisite:

SELECT COUNT(*) AS option_count,
       COALESCE(SUM(OCTET_LENGTH(option_value)), 0) AS value_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Przy zmodyfikowanym filtrze autoload lista wymaga dostosowania. Dodatkowe zapytanie wskazuje duże wpisy:

SELECT option_name, autoload,
       OCTET_LENGTH(option_value) AS value_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY value_bytes DESC
LIMIT 20;

Zapytania nie zmieniają opcji. OCTET_LENGTH liczy bajty zapisanej wartości, a nie znaki ani pamięć PHP. Nazwy, struktury tablic, deserializacja i format pamięci podręcznej powodują dodatkowe lub inaczej rozłożone koszty. Znaczenie ma także mechanizm awaryjny: jeśli zapytanie autoload nie zwróci wierszy, wp_load_alloptions() może następnie pobrać wszystkie opcje. Pusty wynik nie dowodzi zatem braku ładowanych danych.

Znaczenie progu 150 000 bajtów

Bez jawnego ustawienia autoload WordPress ocenia nową lub aktualizowaną wartość za pomocą filtrów. Domyślna reguła rozmiaru daje auto-off po przekroczeniu 150 000 zapisanych bajtów. Dokładnie 150 000 bajtów jeszcze nie przekracza progu. Jawne true daje natomiast on, również dla większej wartości.

Filtr wp_max_autoloaded_option_size może zmienić próg; inne filtry mogą wpływać na decyzję. Nie jest to globalny limit pamięci ani ciągłe porządkowanie wszystkich istniejących opcji. Wartość mająca 102 403 bajty i oznaczenie off nie byłaby na przykład dowodem przekroczenia tego progu.

Aktualny stan tego bloga

Pomiar tylko do odczytu z 24 października 2026 wykazał 31 912 opcji. Do obowiązującej wtedy listy autoload pasowało 156 wpisów: łącznie 113 816 bajtów zapisanych wartości, około 111,1 KiB. Sprawdzanie samego yes nadal nie daje tutaj wyników; występują oznaczenia on, auto i off.

Największe wartości autoload to cron z 51 679 bajtami, rewrite_rules z 16 592 bajtami i wpseo_taxonomy_meta z 15 666 bajtami. Te trzy wartości stanowią razem około 73,7 procent zmierzonych bajtów. Jest to datowany stan danych, a nie pomiar czasu działania ani dowód zbędności wpisów.