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