Оптимизация базы WordPress: что реально работает на практике

Типичная картина: плагин-чистилка сообщает об освобождённых 240 МБ, владелец сайта обновляет главную — и ничего не меняется. Так и должно быть. Размер базы и скорость WordPress связаны слабо: на время отклика влияют объём автозагружаемых опций, количество строк в wp_postmeta и запросы, которые идут мимо индексов. «Освободить место» и «ускорить сайт» — две разные задачи, и обычная чистка решает первую. Ниже — четыре подхода к базе на WordPress 6.x с MySQL 8.0 или MariaDB 10.x, у каждого своя цена.

Сначала замеры, потом чистка

Без трёх цифр любая оптимизация превращается в угадывание. Все команды ниже — WP-CLI 2.x, запускаются из корня сайта. Префикс таблиц у вас может отличаться от wp_.

Что занимает место по таблицам:

wp db size --tables --human-readable

Сколько весит автозагрузка — та часть wp_options, которая читается при каждом запросе:

wp db query "SELECT COUNT(*) AS cnt, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

Набор значений в условии неслучаен: до WordPress 6.6 в колонке autoload жили yes и no, с 6.6 добавились on, off, auto, auto-on, auto-off. Запрос с одним только = 'yes' на свежей установке покажет почти ноль и успокоит вас зря.

Кто именно раздувает автозагрузку:

wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') ORDER BY bytes DESC LIMIT 20;"

Обычно в верхушке списка оказываются кеши лицензий, логи обновлений плагинов, сериализованные настройки конструкторов страниц и транзиенты без срока жизни. Это и есть материал для работы, а не «общий объём базы».

Чистая база — не та, в которой мало строк, а та, в которой каждый частый запрос попадает в индекс, а каждый запрос страницы не тащит мегабайт опций.

Четыре подхода и чем платите за каждый

Плагин-чистилка общего назначения

WP-Optimize, Advanced Database Cleaner и аналоги: кнопка, галочки, расписание. Что выигрываете — чистка без доступа к SSH и SQL, плюс регулярность по cron. Чем платите: плагин работает по типовым правилам и не знает контекста вашего проекта. Он уверенно удалит «осиротевшую» мета — в том числе данные плагина, который вы временно отключили, — и почти никогда не тронет главную причину медленной админки, то есть разросшуюся автозагрузку. Ещё один плагин в автозагрузке, кстати, тоже весит.

Точечная чистка по замерам

Вы нашли конкретную опцию на 4 МБ или 80 000 ревизий и удаляете именно их. Ревизии — только через WP-CLI, не прямым DELETE:

# пачкой по 500, чтобы не упереться в лимит памяти PHP
wp post list --post_type=revision --posts_per_page=500 --format=ids | xargs -r wp post delete --force

Разница принципиальна: wp post delete дёргает штатные хуки и убирает связанные postmeta и связи с терминами, а ручной DELETE FROM wp_posts оставляет за собой мусор, который потом же и попадёт в отчёт чистилки как «осиротевшие записи».

Истёкшие транзиенты:

wp transient delete --expired

Что выигрываете: предсказуемость, удаляете только то, что осознанно выбрали. Чем платите: временем и доступом к консоли, а ещё необходимостью понимать, чей это плагин и зачем ему такая опция. Удалённая запись о лицензии иногда означает повторную активацию платного плагина.

Ограничить рост на входе

Дешевле не чистить, а не накапливать. Две константы в wp-config.php выше строки с подключением wp-settings.php:

// хранить не больше трёх ревизий на запись
define( 'WP_POST_REVISIONS', 3 );

// автоочистка корзины через 7 дней вместо 30 по умолчанию
define( 'EMPTY_TRASH_DAYS', 7 );

Что выигрываете: база перестаёт расти линейно от активности редакторов, и повторять чистку раз в квартал больше не нужно. Чем платите: ограничением ревизий — редактор не откатится на десять версий назад. На редакционном проекте с несколькими авторами это обсуждают с редакцией, а не вводят молча.

Снять нагрузку кешем и индексами

Внешний объектный кеш (Redis или Memcached плюс соответствующий drop-in) убирает повторные чтения опций и транзиентов из MySQL целиком. Автозагрузка при этом не становится меньше, но её вес перестаёт бить по базе на каждом запросе. Побочный эффект, о котором забывают: транзиенты уезжают в Redis, и чистка транзиентов в базе теряет смысл — вы чистите пустое место.

Вторая часть — индексы под тяжёлые выборки по мета-полям. У wp_postmeta в ядре есть индексы по post_id и meta_key, но запрос с фильтром по meta_value (типичный каталог WooCommerce с фильтрами по свойствам) читает лишнее. Схематичный пример составного индекса, который проверяют на копии базы:

ALTER TABLE wp_postmeta
  ADD INDEX meta_key_value ( meta_key(64), meta_value(64) );

Длины префиксов подбирают под конкретные данные, а результат смотрят через EXPLAIN на реальном запросе до и после. Если планировщик индекс не берёт, индекс — это только лишние записи при вставке. Что выигрываете: ускорение конкретных запросов в разы. Чем платите: замедлением записи, лишним объёмом и тем, что ядро о вашем индексе не знает.

Сравнение подходов

Когда что выбирать

1. Автозагрузка перевалила за мегабайт — идите по верхушке списка опций. Ориентир сообщества: до 300–400 КБ беспокоиться не о чем, за мегабайтом у вас почти наверняка сидит один-два виновника. В 6.6 ядро само перестаёт автозагружать слишком большие опции, порог регулируется фильтром и по умолчанию измеряется сотнями килобайт — точное значение сверьте в dev-note к релизу.
2. База большая, но запросы быстрые — не трогайте ничего, кроме констант роста. Место на диске дешевле риска.
3. Тормозит каталог с фильтрами — это не чистка, это индексы и кеш. Чистилка здесь бесполезна.
4. Тормозит админка, список записей или товаров — смотрите автозагрузку и таблицы плагинов: Action Scheduler у WooCommerce, логи антивирусов, таблицы редиректов и 404.
5. Не знаете, какой запрос медленный — поставьте Query Monitor на стейдже и смотрите список запросов страницы. До этого оптимизировать нечего.

Что ломается

• OPTIMIZE TABLE на InnoDB. Команда wp db optimize для InnoDB превращается в полную перестройку таблицы: MySQL честно пишет, что делает recreate плюс analyze. Нужно свободное место под копию таблицы, и на шаред-хостинге процесс спокойно упирается в лимиты. На таблице в несколько гигабайт это не «профилактика», а операция с окном.
• Чистка осиротевшей меты. Плагин отключён на время, а не удалён — его мета уже считается мусором. Восстановить можно только из бэкапа.
• Транзиенты при включённом Redis. Чистите базу, а данные лежат в кеше. Отчёт «удалено 0 записей» здесь корректен.
• Прямой DELETE вместо WP-CLI. Остаются связанные строки в postmeta и term_relationships, а счётчики и кеши остаются невалидными до wp cache flush.
• Свой индекс и обновления ядра. Миграции WordPress о нём не знают. Он обычно выживает, но после крупных обновлений проверяйте, что он на месте и что планировщик его использует.

Что делать дальше

Снимите два показателя до любых изменений: суммарный вес автозагрузки и время самого медленного запроса на проблемной странице по Query Monitor. Дальше — бэкап базы, одно изменение, повторный замер. Один шаг за раз: иначе вы не узнаете, что именно помогло. Прямую доступность Redis и настройку кеширования страниц обсуждать здесь не будем — это отдельная тема, но именно она обычно даёт больший выигрыш, чем любая чистка таблиц.

Автозагрузка (autoload) — пометка в таблице wp_options, означающая, что опцию надо прочитать и положить в память при каждом запросе к сайту, ещё до того, как кто-то её попросит. Полезно для настроек, которые нужны всегда, и вредно для десятка мегабайт кешей, которые нужны раз в сутки.