Если WordPress начал заметно тормозить, а хостинг не показывает явной перегрузки, часто проблема сидит в таблице wp_options. Точнее — в автозагружаемых записях с параметром autoload. Они подгружаются на каждом запросе к сайту, даже если конкретной странице они не нужны. Когда таких опций слишком много или среди них есть тяжёлые записи, время генерации страницы растёт.
Ниже — практичный способ найти лишние autoload-опции, понять, что можно удалять, и очистить таблицу без лишнего риска. Если у вас есть доступ только к панели WordPress, часть шагов можно выполнить через плагин для работы с базой. Если есть доступ к phpMyAdmin или SSH, диагностика будет точнее.
Что именно тормозит сайт в wp_options
Таблица wp_options хранит настройки ядра, темы и плагинов. Для части записей включён автозагрузчик: WordPress забирает их в память при каждом запросе. Это удобно для часто используемых настроек, но вредно, когда:
- в таблице накопились старые записи от удалённых плагинов;
- плагин сохраняет в options большие массивы данных вместо отдельной таблицы;
- в автозагрузку попали временные данные, кэш или служебные записи, которые давно не нужны;
- autoload включён у большого числа мелких опций, и суммарный объём стал слишком большим.
Проблема не в самом факте наличия wp_options, а в том, сколько данных WordPress вынужден читать на каждом запросе. Поэтому чистка должна начинаться не с удаления всего подряд, а с поиска конкретных тяжёлых записей.
Сначала найдите самые тяжёлые autoload-опции
Самый надёжный способ — посмотреть, какие записи с autoload = 'yes' занимают больше всего места. Если у вас есть доступ к базе через phpMyAdmin или другой SQL-клиент, выполните запрос ниже. Он покажет самые крупные автозагружаемые опции.
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;Если префикс таблиц у вас не wp_, замените его на свой. Запрос безопасен: он только читает данные. Смотрите в первую очередь на записи, размер которых явно выбивается из общего списка. Обычно именно они дают основной выигрыш.
Полезно также понять общий объём автозагрузки. Для этого можно посмотреть сумму размеров всех autoload-опций:
SELECT SUM(LENGTH(option_value)) AS total_autoload_bytes
FROM wp_options
WHERE autoload = 'yes';Точный порог «нормы» зависит от сайта, темы и набора плагинов. Но если автозагрузки стало слишком много, это обычно видно сразу: список тяжёлых записей длинный, а среди них есть явно лишние данные от давно удалённых расширений.
Как понять, что можно удалить, а что трогать нельзя
На этом шаге важна аккуратность. В wp_options есть записи, без которых сайт сломается, и есть мусор, который можно удалить без последствий. Сначала ориентируйтесь по названию опции:
- записи с именами удалённых плагинов, старых тем или временных модулей обычно можно убрать;
- служебные опции ядра WordPress лучше не трогать, если вы не уверены в их назначении;
- если название похоже на кэш, лог, transient, временные данные или старый модуль, это кандидат на удаление, но сначала проверьте источник;
- если опция относится к активной теме, текущему плагину или настройкам сайта, удалять её без понимания последствий не стоит.
Практический ориентир простой: если плагин уже удалён, а его опция осталась в базе и при этом весит много — это почти всегда лишнее. Если плагин активен, сначала ищите его настройки в админке или документации. У некоторых расширений данные в wp_options нужны для нормальной работы.
Безопасная очистка через SQL
Перед удалением сделайте резервную копию базы данных. Это не формальность: одна неверная строка в SQL может убрать нужную настройку и сломать сайт или админку. Если не уверены в названии опции, сначала проверьте её содержимое и источник.
Удалять одну конкретную запись можно так:
DELETE FROM wp_options
WHERE option_name = 'example_option_name';Если нужно убрать группу записей, которые точно относятся к удалённому плагину, используйте более точное условие по имени. Например, так можно удалить все опции с определённым префиксом:
DELETE FROM wp_options
WHERE option_name LIKE 'old_plugin_%';После удаления проверьте сайт и админку. Если что-то перестало работать, восстановите базу из бэкапа. Не удаляйте записи по принципу «всё, что большое». Размер сам по себе не означает, что опция лишняя.
Когда лучше не удалять, а перевести autoload в no
Иногда запись нужна сайту, но её не нужно подгружать на каждом запросе. В таком случае правильнее не удалять её, а отключить автозагрузку. Это полезно для опций, которые используются редко, но должны оставаться в базе.
Изменить автозагрузку можно так:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'example_option_name';Такой подход безопаснее удаления, если вы не уверены, нужна ли запись плагину. Но и здесь сначала проверьте, что опция действительно не должна загружаться постоянно. Некоторые плагины рассчитывают на автозагрузку своих настроек и могут работать медленнее или нестабильно после изменения.
Если доступа к базе нет: как почистить через админку
Когда хостинг не даёт доступ к phpMyAdmin или SSH, остаётся работать через WordPress. Для этого удобнее использовать плагин, который показывает содержимое базы и позволяет удалять записи вручную. Подход подходит не для массовой автоматической чистки, а для точечного удаления очевидного мусора.
Порядок действий такой:
- Сделайте резервную копию сайта и базы через панель хостинга или плагин бэкапа.
- Откройте инструмент для просмотра таблиц базы данных.
- Найдите
wp_options. - Отсортируйте записи по размеру или найдите по имени подозрительные опции.
- Удаляйте только те записи, происхождение которых вам понятно.
Если плагин показывает только список опций без удобной сортировки по размеру, такой способ годится лишь для ручной проверки известных проблемных записей. Для серьёзной чистки удобнее всё-таки работать через SQL.
Как проверить, что очистка сработала
После удаления или перевода опций в autoload = 'no' проверьте три вещи.
- Сайт открывается без ошибок. Пройдитесь по главной странице, нескольким внутренним страницам и админке.
- Список тяжёлых autoload-опций стал короче. Повторите SQL-запрос на выборку самых крупных записей и сравните результат до и после.
- Страница стала загружаться быстрее. Оценивать лучше не по ощущениям, а по инструментам вроде Query Monitor, PageSpeed Insights или встроенной статистики хостинга.
Если после чистки сайт начал вести себя странно, откатите изменения из резервной копии. Обычно проблема не в самой идее очистки, а в том, что удалили нужную опцию или перевели в no запись, которую плагин ожидал видеть в автозагрузке.
Что делать, если тяжёлых записей много и они возвращаются
Если вы удалили мусор, а через некоторое время в wp_options снова появляются крупные autoload-опции, значит источник проблемы не устранён. Обычно это один из сценариев:
- плагин продолжает писать данные в options вместо отдельной таблицы;
- на сайте остался старый плагин, который создаёт новые записи при каждом обновлении;
- тема или плагин хранит в options кэш, который не очищается корректно;
- на сайте есть несколько расширений, которые одновременно раздувают базу.
В такой ситуации полезно не просто чистить базу, а найти конкретный источник. Отключайте плагины по одному, проверяйте список autoload-опций после каждого шага и фиксируйте, после какого расширения появляются новые тяжёлые записи. Это быстрее, чем удалять последствия снова и снова.
Если нужен более системный подход к чистке сайта, можно использовать инструменты оптимизации и удаления дублей, но они не заменяют ручную проверку wp_options. Автозагрузку всё равно лучше контролировать глазами, особенно если сайт уже заметно проседает по скорости.