Если сайт на WordPress начал заметно тормозить, а в базе данных разрослась таблица wp_options, проблема часто сидит не в самом WordPress, а в автозагружаемых опциях. Именно они поднимаются при каждом запросе к сайту, и если их слишком много или среди них есть тяжёлые записи от плагинов, это бьёт по времени ответа и памяти.
Чистить wp_options можно безопасно, но только если понимать, что именно удаляете. Эта таблица хранит не только мусор, но и критичные настройки сайта, темы и плагинов. Ниже — рабочий порядок действий: сначала диагностика, потом чистка, затем проверка результата.
Что именно тормозит: автозагрузка и мусорные опции
В wp_options есть поле autoload. Если у записи значение yes, WordPress подгружает её почти на каждый запрос. Это удобно для небольших настроек, но вредно, когда в автозагрузке оказываются большие массивы данных, временные записи старых плагинов, следы удалённых расширений или дубли настроек.
Обычно проблема проявляется так:
- админка открывается медленнее обычного;
- страницы сайта дольше генерируются без видимой причины;
- в базе растёт объём таблицы
wp_options; - хостинг показывает повышенную нагрузку на MySQL;
- после удаления плагина его опции остаются в базе.
Если сайт работает на общем хостинге, даже несколько лишних мегабайт в автозагрузке могут быть заметны. На более мощном сервере эффект тоже есть, просто он проявляется не так резко.
Сначала проверьте, что именно разрослось
Перед чисткой нужно увидеть состав таблицы. Самая полезная проверка — размер автозагружаемых опций и список самых тяжёлых записей. Если у вас есть доступ к phpMyAdmin или другому SQL-клиенту, выполните запросы ниже. Перед любыми изменениями сделайте резервную копию базы данных.
Чтобы посмотреть общий объём автозагрузки:
SELECT ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';Чтобы увидеть самые тяжёлые записи в автозагрузке:
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;Если префикс таблиц у вас не wp_, замените его на свой. В результатах ищите не только большие значения, но и знакомые названия плагинов, которые вы уже удалили или не используете.
Безопасная чистка: что можно удалять, а что трогать нельзя
Удалять подряд всё подряд нельзя. В wp_options лежат настройки сайта, темы, постоянные кэши и системные параметры. Ошибка здесь может сломать вход в админку, сбросить настройки темы или отключить плагин.
Обычно можно рассматривать для удаления такие записи:
- опции удалённых плагинов, если сам плагин уже деинсталлирован;
- временные записи старых расширений, которые больше не используются;
- дубли и хвосты после миграций или неудачных обновлений;
- транзиенты, если они застряли в базе и давно не нужны.
Трогать без понимания не стоит:
siteurlиhome;- настройки активной темы;
- опции активных плагинов;
- служебные записи WordPress, если вы не уверены в их назначении.
Если вы не можете точно определить запись, лучше сначала проверить, какой плагин её создал. По названию опции это часто видно: у большинства расширений есть понятный префикс.
Как удалить мусорные записи вручную
Ручная чистка подходит, когда вы видите конкретные проблемные опции и понимаете, откуда они взялись. Это самый контролируемый способ, но он требует аккуратности.
Сначала найдите записи, связанные с удалённым плагином. Например, если плагин больше не нужен, а в базе остались его опции, можно удалить их по имени или по шаблону. Делайте это только после проверки списка найденных строк.
Пример запроса для поиска опций по части имени:
SELECT option_name, autoload
FROM wp_options
WHERE option_name LIKE '%plugin_prefix%';Если вы уверены, что найденные записи относятся к удалённому плагину и не нужны сайту, удалите их точечно:
DELETE FROM wp_options
WHERE option_name LIKE '%plugin_prefix%';После этого обновите кэш сайта и проверьте админку, главную страницу и несколько внутренних страниц. Если что-то сломалось, восстановите базу из резервной копии.
Что делать с автозагрузкой, если опцию удалять нельзя
Иногда запись нужна, но она слишком тяжёлая для автозагрузки. В этом случае лучше не удалять её, а отключить автозагрузку. Это подходит для опций, которые используются редко и не нужны на каждом запросе.
В MySQL это можно сделать так:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'example_option';Такой шаг уменьшает объём данных, которые WordPress поднимает при каждом запросе. Но не переводите в no всё подряд: если опция нужна ядру, теме или активному плагину на каждом хите, сайт может начать работать нестабильно. Обычно автозагрузку меняют только для явно тяжёлых и второстепенных записей.
Транзиенты и временные данные: когда их можно чистить
Транзиенты — это временные данные, которые WordPress и плагины используют для кэша. Часть из них удаляется автоматически, но на некоторых сайтах остаются устаревшие записи. Если база давно не чистилась, транзиенты могут занимать заметный объём.
Удалять их можно, если вы понимаете, что это именно временный кэш, а не важные настройки. После очистки сайт просто пересоздаст нужные данные заново. Обычно это безопаснее, чем удаление постоянных опций, но всё равно лучше делать это после резервной копии.
Если у вас есть доступ к WP-CLI, удобнее всего чистить именно транзиенты через него. Но если WP-CLI недоступен на хостинге, можно ограничиться ручной проверкой в базе и удалением только очевидно устаревших записей.
Как не сломать сайт во время чистки
Самая частая ошибка — удалять записи по одному только размеру. Большая опция не всегда мусор. Некоторые плагины хранят в базе большие наборы правил, шаблонов или кэша, и без них сайт теряет функциональность.
Перед изменениями соблюдайте простой порядок:
- сделайте резервную копию базы данных;
- посмотрите список самых тяжёлых автозагружаемых опций;
- определите, какие записи относятся к удалённым плагинам;
- удаляйте только то, что можете объяснить;
- после каждого шага проверяйте сайт.
Если сайт клиентский или коммерческий, лучше сначала выполнить чистку на копии или staging-версии. Это особенно важно, когда в базе много старых плагинов и непонятных записей после миграций.
Как проверить, что оптимизация сработала
После чистки нужно убедиться, что вы действительно уменьшили нагрузку, а не просто удалили часть данных. Сравните размер автозагрузки до и после. Если он заметно снизился, это уже хороший признак.
Проверьте ещё три вещи:
- главная страница и несколько внутренних страниц открываются без ошибок;
- админка работает нормально, особенно разделы с настройками темы и плагинов;
- в базе больше нет старых опций удалённых расширений.
Если у вас есть мониторинг сервера или отчёты хостинга, посмотрите время ответа MySQL и общую нагрузку после очистки. Иногда эффект заметен не сразу в интерфейсе, а именно в снижении фоновой нагрузки.
Когда лучше не чистить вручную
Ручная работа с wp_options не лучший вариант, если вы не можете отличить системную запись от мусорной, если сайт давно поддерживается разными подрядчиками или если база уже повреждена. В таких случаях безопаснее сначала сделать полную копию, затем разбирать таблицу по конкретным плагинам и только после этого удалять лишнее.
Если проблема повторяется регулярно, причина обычно не в самой таблице, а в плагине, который плодит тяжёлые опции или оставляет хвосты после удаления. Тогда имеет смысл не только чистить базу, но и заменить источник проблемы.
Для сайтов, где нужно регулярно следить за мусором, дублирующимися настройками и общим «разрастанием» базы, удобно использовать инструменты оптимизации вроде Clearfy Pro: он не заменяет ручную проверку базы, но помогает убрать часть лишнего и поддерживать сайт в более аккуратном состоянии. Если же в wp_options уже накопились конкретные тяжёлые записи, сначала всё равно разберитесь с ними вручную, а не полагайтесь только на плагин.
Главный принцип здесь простой: в wp_options чистят не «всё лишнее», а только то, что можно точно идентифицировать. Тогда таблица становится легче, автозагрузка уменьшается, а сайт перестаёт тратить ресурсы на старый мусор.