Если сайт на WordPress начал заметно тяжелее открываться, а в базе разрослась таблица wp_options, часто проблема не в одном «тяжёлом» плагине, а в накопившихся автозагружаемых опциях. WordPress подгружает такие значения на каждый запрос, поэтому лишние записи с autoload = 'yes' напрямую бьют по скорости и памяти.
Задача здесь не в том, чтобы без разбора чистить всё подряд, а в том, чтобы найти устаревшие автозагрузки, понять, кому они принадлежат, и удалить только то, что действительно больше не используется. Это можно сделать безопасно, если идти по шагам: сначала посмотреть, что именно грузится, затем проверить источник опций, после этого удалить мусор и убедиться, что сайт работает как раньше.
Что именно нужно искать в wp_options
В таблице wp_options хранятся настройки ядра, темы и плагинов. Часть этих записей помечена как автозагружаемая: WordPress поднимает их в память при каждом запросе, чтобы не делать отдельный запрос к базе для каждой опции. Это удобно для небольшого числа настроек, но вредно, когда в автозагрузку попадает большой объём данных или старые записи от удалённых плагинов.
Проблемными обычно становятся:
- опции от плагинов, которые уже удалены, но их данные остались в базе;
- кэшированные массивы и временные данные, которые почему-то записаны как
autoload = 'yes'; - дубли настроек после неудачных обновлений или миграций;
- опции, которые больше не используются темой или плагином, но продолжают загружаться на каждом запросе.
Важно понимать: не каждая большая запись в wp_options лишняя. Некоторые плагины действительно хранят там нужные данные. Удалять нужно только то, в чьём назначении вы уверены.
Сначала найдите самые тяжёлые автозагружаемые опции
Самый практичный способ — посмотреть, какие записи занимают больше всего места и имеют автозагрузку. Если у вас есть доступ к phpMyAdmin или другому SQL-клиенту, можно начать с такого запроса:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;Если префикс таблиц у вас не wp_, замените его на свой. Запрос покажет самые крупные автозагружаемые значения. Обычно именно среди них проще всего найти мусор: старые кэши, массивы настроек удалённых расширений, лишние transient-подобные записи, если они были сохранены неправильно.
Полезно также посмотреть общий объём автозагрузки:
SELECT SUM(LENGTH(option_value)) AS autoload_size_bytes
FROM wp_options
WHERE autoload = 'yes';Сам по себе объём не говорит, что сайт сломан, но если автозагрузка разрослась до заметных значений, это уже повод разбирать содержимое.
Определите, что можно удалить, а что трогать нельзя
Перед удалением нужно понять происхождение опции. Название часто подсказывает, к какому плагину или теме она относится. Например, в имени может быть явный префикс разработчика или название расширения. Если плагин уже удалён, а запись осталась, это хороший кандидат на очистку. Если же опция относится к активной теме, ядру WordPress или текущему плагину, удалять её без проверки нельзя.
Ориентируйтесь на такие признаки:
- Безопаснее удалять записи, которые явно принадлежат удалённому плагину или старой теме.
- Нужно проверить вручную опции с общими названиями, которые могут использоваться несколькими компонентами.
- Лучше не трогать системные настройки WordPress, параметры активной темы, данные кэша активных плагинов и всё, что влияет на авторизацию, URL сайта, структуру постоянных ссылок и поведение админки.
Если вы не уверены в назначении записи, сначала найдите её по имени в файлах плагина или темы. Иногда достаточно поиска по каталогу wp-content/plugins или wp-content/themes, чтобы понять, используется ли опция вообще.
Как безопасно удалить устаревшие autoload-значения
Самый надёжный порядок действий такой: сначала резервная копия базы, потом удаление, потом проверка. Без бэкапа чистить wp_options не стоит, потому что ошибка в одном запросе может сломать сайт или админку.
Если вы работаете через SQL, удаляйте только те записи, в которых уверены. Пример для конкретной опции:
DELETE FROM wp_options
WHERE option_name = 'old_plugin_setting';Если нужно убрать несколько точно идентифицированных записей, можно использовать список:
DELETE FROM wp_options
WHERE option_name IN (
'old_plugin_setting_1',
'old_plugin_setting_2',
'old_plugin_setting_3'
);Не советую массово удалять всё подряд по шаблону имени, если вы не проверили, что именно входит в выборку. В WordPress и плагинах нередко встречаются похожие названия, и одна лишняя запись может оказаться нужной.
Если у вас есть WP-CLI, можно действовать аккуратнее через него. Например, сначала посмотреть значение, а потом удалить конкретную опцию:
wp option get old_plugin_setting
wp option delete old_plugin_settingWP-CLI удобен тем, что вы работаете с конкретной опцией, а не вручную редактируете SQL. Но он доступен не на каждом хостинге, и это зависит от окружения.
Когда лучше не удалять, а перевести опцию из autoload в обычную
Иногда запись нужна, но не должна грузиться на каждом запросе. В таком случае удаление не подходит: правильнее изменить флаг автозагрузки на no. Это полезно для больших настроек, которые используются редко, например в админке, но не нужны на фронтенде постоянно.
Для одной опции это можно сделать SQL-запросом:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'heavy_but_needed_option';Такой подход безопаснее, чем удаление, если вы точно знаете, что значение должно остаться в базе. Но здесь тоже нужна осторожность: если плагин ожидает автозагрузку для критичных настроек, изменение поведения может привести к ошибкам. После такого изменения обязательно проверьте сайт и админку.
Как проверить, что очистка прошла без побочных эффектов
После удаления или изменения автозагрузки не ограничивайтесь открытием главной страницы. Проверьте несколько сценариев, которые реально завязаны на настройки сайта:
- открывается ли главная страница и несколько внутренних страниц;
- работает ли вход в админку;
- не сломались ли формы, меню, виджеты и блоки темы;
- не появились ли ошибки в журнале сервера или в
debug.log, если он у вас включён; - не изменилось ли поведение активных плагинов, которые могли использовать удалённую опцию.
Если после очистки сайт стал быстрее, но в админке или на фронтенде появились странности, первым делом проверьте, не была ли удалена нужная настройка. В таких случаях резервная копия базы экономит много времени: можно вернуть состояние и повторить очистку уже точечно.
Как не превратить wp_options в свалку снова
Полностью исключить рост wp_options нельзя: плагины и темы всё равно добавляют свои настройки. Но можно не допускать накопления мусора. Практически это сводится к трём вещам.
- Удаляйте плагин не только через админку, но и проверяйте, оставил ли он после себя опции в базе.
- Не держите на сайте расширения, которые давно не используются, особенно если они активно пишут данные в
wp_options. - Периодически проверяйте автозагрузку, если сайт активно развивается, часто меняются темы и набор плагинов.
Если вы ведёте несколько сайтов, имеет смысл раз в какое-то время смотреть именно на самые тяжёлые автозагружаемые записи. Это быстрее, чем разбирать всю таблицу вручную, и обычно даёт понятный результат без лишнего риска.
Для более удобной чистки и контроля за лишними данными в WordPress иногда используют инструменты оптимизации и удаления дублей, например Clearfy Pro, но даже с такими решениями полезно понимать, что именно вы удаляете и почему. Автоматизация помогает, а не заменяет проверку.
Если коротко: ищите крупные записи с autoload = 'yes', определяйте их источник, удаляйте только устаревшие и ненужные, а нужные, но тяжёлые — переводите в no. Такой подход безопаснее, чем массовая «чистка базы», и обычно даёт именно тот эффект, ради которого вообще лезут в wp_options: меньше лишней нагрузки и более быстрый сайт.
