Если WordPress стал заметно медленнее без видимой причины, а база данных в целом выглядит нормальной, часто проблема сидит не в «тяжёлых запросах вообще», а в автозагружаемых опциях. Это записи из таблицы wp_options, которые WordPress подгружает на каждом запросе. Когда таких данных слишком много или среди них есть большие массивы, сайт начинает тратить лишнюю память и время ещё до того, как дойдёт до шаблона.
Здесь важно не путать autoload-проблему с общей «раздутой базой». Можно иметь вполне небольшую базу, но один или несколько плагинов оставили после себя крупные опции с автозагрузкой. Именно их и нужно искать в первую очередь.
Что именно нужно искать в базе
В WordPress автозагрузка задаётся полем autoload в таблице wp_options. Для опций со значением yes WordPress поднимает их в память при каждом запросе. Это удобно для небольших и часто используемых настроек, но вредно, если туда попали большие данные: кэш, списки, логи, временные массивы, следы удалённых плагинов.
Проверять стоит не все опции подряд, а те, которые:
- имеют большой размер;
- относятся к плагинам, которые вы уже удалили или не используете;
- содержат кэш, временные данные, статистику, журналы, списки объектов;
- явно не нужны на каждом запросе сайта.
Безопаснее всего начинать с поиска самых крупных автозагружаемых записей. Это даёт быстрый эффект и снижает риск случайно удалить что-то нужное.
Как найти тяжёлые autoload-опции
Если у вас есть доступ к phpMyAdmin или другому SQL-интерфейсу, начните с выборки самых крупных автозагружаемых записей. Для стандартной установки WordPress таблица называется wp_options, но префикс может быть другим.
Запрос для поиска крупных autoload-опций:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;Этот запрос покажет, какие записи занимают больше всего места. Если нужно увидеть размер в более понятном виде, можно добавить перевод в килобайты, но для диагностики достаточно и байтов.
Если вы работаете через WP-CLI, можно получить тот же результат через SQL-запрос:
wp db query "SELECT option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE autoload = 'yes' ORDER BY size_bytes DESC LIMIT 50;"На практике полезно смотреть не только на абсолютный размер, но и на названия опций. Часто сразу видно, к какому плагину они относятся. Если запись выглядит как служебный кэш или временные данные, её можно проверить в первую очередь.
На что обращать внимание в списке
Подозрительными обычно выглядят опции с названиями, которые содержат слова вроде cache, transient, log, stats, backup, session, а также длинные массивы с префиксом конкретного плагина. Но ориентироваться только на имя нельзя: у некоторых плагинов нормальные настройки тоже могут быть объёмными.
Если опция принадлежит активному плагину, сначала проверьте, есть ли у него собственные настройки очистки кэша или отключения хранения данных. Удалять такую запись вручную без понимания последствий не стоит.
Какие записи обычно можно проверить без риска
Самый безопасный порядок такой: сначала смотрите на опции от уже удалённых плагинов, затем на кэш и временные данные, и только потом на настройки активных расширений. Если плагин удалён, а его опции остались в базе, они не нужны сайту и только раздувают autoload.
Чаще всего можно проверить:
- опции от плагинов, которых больше нет в списке установленных;
- старые кэши и временные массивы;
- служебные данные, которые плагин должен пересоздавать автоматически;
- остатки после миграций, тестов и неудачных обновлений.
Если запись выглядит как основная настройка активного плагина, не удаляйте её сразу. Иногда плагин хранит в одной опции не только настройки, но и важные данные для работы. В таком случае лучше сначала проверить документацию плагина или временно отключить autoload, а не удалять запись целиком.
Как безопасно удалить или отключить автозагрузку
Перед любыми изменениями сделайте резервную копию базы данных. Это не формальность: если удалить не ту опцию, можно сломать работу темы, плагина или части админки. Бэкап нужен именно перед ручной правкой wp_options.
Есть два подхода: удалить запись полностью или оставить её в базе, но выключить автозагрузку. Второй вариант часто безопаснее для проверки, потому что данные сохраняются, а WordPress перестаёт поднимать их на каждом запросе.
Чтобы отключить автозагрузку у конкретной опции, выполните:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'имя_опции';Если вы уверены, что запись больше не нужна, можно удалить её:
DELETE FROM wp_options
WHERE option_name = 'имя_опции';После этого очистите объектный кэш, если он используется, и сбросьте кэш страницы, если у вас есть плагин кеширования или серверный кэш. Иначе вы можете не увидеть эффект сразу.
Если работаете через WP-CLI, для изменения значения можно использовать SQL-запрос из командной строки. Но перед этим убедитесь, что подключаетесь к правильной базе и таблица действительно относится к нужному сайту, особенно если на хостинге несколько установок WordPress.
Как проверить, что проблема действительно была в autoload
После очистки нужно проверить не только скорость страницы в браузере, но и сам объём автозагружаемых данных. Иначе легко удалить одну тяжёлую запись и оставить ещё несколько таких же.
Для проверки снова выполните запрос к самым крупным autoload-опциям и сравните результат до и после. Если вы отключили или удалили действительно тяжёлую запись, она исчезнет из списка или заметно уменьшится общий объём.
Полезно также посмотреть суммарный размер всех автозагружаемых опций:
SELECT SUM(LENGTH(option_value)) AS total_autoload_bytes
FROM wp_options
WHERE autoload = 'yes';Если сумма была слишком большой, а после чистки заметно снизилась, это хороший признак. В реальной работе WordPress это обычно означает меньшую нагрузку на память и более быстрый старт запроса, особенно на сайтах с большим количеством плагинов.
Когда лучше не трогать запись вручную
Есть ситуации, в которых ручное удаление autoload-опции приносит больше вреда, чем пользы. Не трогайте запись, если вы не понимаете, к какому плагину она относится, и если это похоже на основную настройку активного компонента. Также осторожность нужна, когда сайт использует сложные интеграции, мультиязычность, кэширование на уровне объекта или нестандартные плагины, которые хранят важные данные в одной большой опции.
Если сомневаетесь, сначала отключите автозагрузку, а не удаляйте запись. Это позволяет проверить, не ломается ли сайт, и при необходимости быстро вернуть значение autoload обратно в yes.
Ещё один практический момент: после обновлений плагинов старые autoload-данные иногда остаются в базе, хотя сам плагин уже хранит настройки иначе. В таких случаях полезно сначала удалить остатки только после того, как вы убедились, что плагин работает без них.
Что делать, если тяжёлых autoload-опций несколько
Если список показывает сразу несколько крупных записей, не пытайтесь чистить всё подряд за один заход. Удобнее идти по одной опции: отключили автозагрузку, проверили сайт, затем перешли к следующей. Так проще понять, какая запись действительно мешала, а какая была нормальной частью работы плагина.
На сайтах с долгой историей обычно встречается не одна проблема, а набор мелких. Один плагин оставил кэш, другой — старые настройки после удаления, третий — большой массив статистики. В этом случае эффект даёт именно последовательная чистка, а не массовое удаление всего подряд.
Если у вас нет доступа к базе или вы не хотите править её вручную, можно использовать плагин для работы с опциями и очистки мусора. Но даже в этом случае принцип тот же: сначала находите крупные autoload-записи, потом проверяете, к чему они относятся, и только после этого принимаете решение об удалении или отключении автозагрузки.
Главная идея простая: WordPress тормозит не из-за факта наличия опций, а из-за того, что слишком много лишних данных подгружается на каждом запросе. Если убрать из autoload всё, что не нужно постоянно, сайт обычно начинает работать заметно легче без радикальных изменений в коде и архитектуре.