Если сайт на WordPress начал заметно тормозить, а в админке и на фронтенде нет явной причины, часто проблема сидит в таблице wp_options. Туда плагинами и темой складываются настройки, кэш, временные данные и служебные записи. Часть из них помечается как автозагружаемая — WordPress поднимает такие опции на каждом запросе. Когда их слишком много или они слишком тяжёлые, растёт время загрузки страниц и расход памяти.
Очистка wp_options обычно даёт эффект не потому, что таблица «большая», а потому, что в ней остаются старые записи от удалённых плагинов, дубли настроек и лишний autoload. Ниже — рабочий порядок действий: как найти проблемные записи, что можно удалить, а что лучше не трогать, и как проверить результат.
Сначала найдите, что именно раздувает wp_options
Не начинайте с массового удаления. В wp_options есть критичные системные записи, и ошибка здесь легко ломает сайт или админку. Сначала нужно понять, какие опции занимают место и какие из них автозагружаются.
Самый надёжный способ — посмотреть таблицу через phpMyAdmin, Adminer или другой доступный инструмент SQL. Если есть доступ к базе, выполните запрос на самые тяжёлые автозагружаемые записи:
SELECT option_name, LENGTH(option_value) AS size_bytes, autoload
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;Этот запрос покажет, какие записи реально грузятся на каждом запросе и сколько места они занимают. Если префикс таблиц у вас не wp_, подставьте свой.
Полезно отдельно посмотреть, сколько вообще автозагружаемых данных лежит в таблице:
SELECT SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload = 'yes';Если сумма измеряется мегабайтами, это уже повод разбираться. Для обычного сайта автозагрузки должно быть немного; точной «нормы» нет, но большой объём почти всегда означает лишние записи или неудачную работу плагинов.
Что можно чистить без риска, а что лучше не трогать
В wp_options смешаны разные типы данных. Часть можно удалить, часть — только отключить от автозагрузки, а часть вообще не трогать вручную.
| Тип записи | Что с ней делать | Комментарий |
|---|---|---|
| Старые опции удалённых плагинов | Удалять | Если плагин давно удалён и запись не нужна текущему сайту |
| Временные данные, кэш, transient-опции | Обычно удалять можно | WordPress и плагины пересоздадут их при необходимости |
| Тяжёлые, но нужные опции активных плагинов | Лучше убрать из автозагрузки, а не удалять | Удаление может сломать настройки плагина |
| Системные записи WordPress | Не трогать вручную | Например, siteurl, home, active_plugins, template, stylesheet |
Если сомневаетесь, сначала ищите имя плагина в названии опции. Часто мусорные записи легко узнаются по префиксу конкретного расширения. Удалять их безопаснее после проверки, что плагин действительно не используется.
Как убрать мусорные записи из wp_options
Самый безопасный сценарий — сначала сделать резервную копию базы данных. Это не формальность: если удалить не ту запись, восстановление из бэкапа будет самым быстрым способом вернуть сайт в рабочее состояние.
После бэкапа можно удалять очевидный мусор. Например, если вы нашли старые опции удалённого плагина, используйте точечное удаление по имени:
DELETE FROM wp_options
WHERE option_name = 'имя_опции';Если записей несколько и они явно относятся к одному удалённому плагину, можно удалить их по шаблону, но только когда вы уверены в результате:
DELETE FROM wp_options
WHERE option_name LIKE 'prefix_%';Такой запрос опаснее, чем точечное удаление. Перед ним обязательно проверьте, какие строки попадут под условие:
SELECT option_name
FROM wp_options
WHERE option_name LIKE 'prefix_%';Если список содержит что-то нужное текущему сайту, не удаляйте всё подряд.
Как снизить autoload без удаления нужных настроек
Иногда проблема не в мусоре, а в том, что активный плагин хранит слишком тяжёлую опцию с autoload = yes. Удалять такую запись нельзя, потому что она нужна работе плагина. В этом случае правильнее отключить автозагрузку и оставить саму опцию в базе.
Для этого сначала проверьте, действительно ли запись нужна. Если это настройка активного плагина, а не кэш или временные данные, можно поменять значение autoload на no:
UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'имя_опции';После этого WordPress не будет поднимать эту запись на каждом запросе. Но делать так стоит только для опций, которые не нужны постоянно при каждом обращении к сайту. Если плагин читает их на каждом хите, он может начать работать медленнее или даже некорректно. Поэтому здесь важна проверка: сначала смотрим, что это за опция, потом меняем автозагрузку.
На практике чаще всего в autoload попадают:
- кэшированные массивы настроек;
- данные старых версий плагинов;
- временные служебные записи, которые давно не очищались;
- настройки, которые плагин по ошибке пометил как автозагружаемые.
Проверка после очистки
После удаления мусора и переноса тяжёлых опций из автозагрузки проверьте две вещи: объём autoload и поведение сайта.
Снова выполните запрос на сумму автозагружаемых данных и сравните результат с тем, что было до очистки:
SELECT SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload = 'yes';Затем откройте главную страницу, несколько внутренних страниц и админку. Если сайт использует кэш, очистите его перед проверкой, чтобы увидеть реальную картину. Обратите внимание на:
- время открытия админки;
- скорость загрузки страниц на фронтенде;
- ошибки в логах, если они доступны;
- не пропали ли настройки плагинов после удаления записей.
Если после чистки что-то сломалось, почти всегда причина в слишком агрессивном удалении или в том, что нужной опции ошибочно поставили autoload = no. В таком случае возвращайтесь к бэкапу и меняйте только конкретную запись, а не всю таблицу.
Когда лучше не чистить вручную
Ручная работа с wp_options подходит, когда вы понимаете, какие записи удаляете. Но если сайт большой, плагинов много, а в базе десятки тысяч опций, безопаснее сначала провести аудит. На таких проектах полезно искать не только мусор, но и источник его появления: старые плагины, дублирующие функции, неочищаемые кэши, криво написанные интеграции.
Если у вас нет уверенности в SQL-запросах или доступе к резервной копии, не начинайте с массовых операций. Сначала снимите бэкап, потом удаляйте только очевидно лишнее. Это особенно важно на живом сайте с трафиком: ошибка в wp_options бьёт не по одной странице, а по всему WordPress сразу.
Для регулярной чистки и отключения лишних автозагрузок можно использовать плагины оптимизации, но и там принцип тот же: сначала проверка, потом удаление. Автоматическая чистка удобна, когда вы понимаете, что именно она делает. Если нет — ручной аудит надёжнее.
Итог простой: чтобы очистить wp_options от автозагрузки и мусорных записей, сначала находят тяжёлые опции, затем удаляют только остатки удалённых плагинов и временные данные, а нужным, но тяжёлым записям отключают autoload. Именно такой порядок даёт эффект без лишнего риска для сайта.