Безопасная очистка WordPress Transients через WP-CLI

Что такое WordPress Transients и почему они накапливаются

Transient — это временное значение с ограниченным сроком действия. WordPress сохраняет его под отдельным ключом и возвращает плагину или теме, пока оно не устареет. Например, таким способом могут кэшироваться курсы валют, ответы внешнего API, списки товаров, результаты сложных запросов или данные виджета.

При отсутствии постоянного объектного кэша transients обычно хранятся в таблице wp_options. Для каждого значения WordPress может создавать основную запись и отдельную служебную запись со временем окончания действия. Большое количество таких записей увеличивает размер таблицы, усложняет обслуживание базы данных и может добавлять лишние операции при работе с options.

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

• кэширование ответов внешних сервисов и API;
• временное хранение результатов ресурсоёмких SQL-запросов;
• кэширование фрагментов страниц или данных виджетов;
• хранение служебных значений во время работы плагинов.

Почему не стоит удалять Transients прямым SQL-запросом

Прямое удаление строк из wp_options может показаться быстрым решением, но оно обходит API WordPress. В результате можно удалить актуальные значения, служебные ключи или записи, которые плагин ещё использует. Отдельный риск — неправильный SQL-фильтр, который затронет не только transients, но и другие настройки сайта.

Названия ключей transient могут содержать префиксы конкретных плагинов, а их формат и логика создания различаются. Даже если запись уже устарела, лучше удалять её через WP-CLI или функции WordPress, чтобы не зависеть от внутренней структуры таблицы.

SQL может быть уместен во время специальной процедуры восстановления или миграции, если у вас есть актуальная резервная копия, план отката и понимание структуры данных. Для регулярного обслуживания сайта это не основной метод.

• не удаляйте все записи по шаблону _transient_% без проверки;
• не запускайте очистку на рабочем сайте без резервной копии или возможности восстановления;
• не путайте transients с обычными настройками плагинов в wp_options.

Подготовка к очистке через WP-CLI

Перед запуском команды проверьте, что WP-CLI работает в каталоге установки WordPress и имеет доступ к нужному сайту и базе данных. На сервере с несколькими сайтами важно не перепутать корневой каталог или конфигурацию конкретного окружения.

Создайте резервную копию базы данных или убедитесь, что у вас есть свежая копия, из которой можно восстановить сайт. Это особенно важно перед полным удалением transients, поскольку после него плагины начнут создавать кэш заново.

До очистки полезно зафиксировать базовые показатели: время ответа, ошибки PHP, нагрузку на сервер и количество записей. Так будет понятно, действительно ли процедура дала результат, а не просто изменила симптомы.

• проверьте доступ по SSH и работоспособность команды wp;
• убедитесь, что команда запускается для правильного WordPress-сайта;
• по возможности запланируйте операцию на период невысокой нагрузки;
• предупредите команду, если после очистки ожидается временный рост числа API-запросов.

wp --info
wp core is-installed
wp transient list --fields=name,expiration --format=table

Как удалить только устаревшие Transients

Для стандартной осторожной очистки используйте команду, которая удаляет только transients с истёкшим сроком действия:

Это лучший первый шаг, если вы видите накопление временных записей, но не имеете причин сбрасывать весь кэш. Актуальные значения сохранятся, поэтому количество повторных запросов к API и перестроений кэша будет меньше.

После выполнения команды проверьте её вывод и посмотрите, как изменились размер базы данных, время ответа и журналы ошибок. Если устаревшие записи быстро появляются снова, проблема может быть не в самой очистке, а в плагине, который создаёт слишком много уникальных ключей.

• запускайте команду с правами пользователя, имеющего доступ к нужному WordPress;
• без необходимости не прерывайте процесс на большой базе данных;
• после очистки проверьте основные страницы, формы, корзину, авторизацию и функции, зависящие от API.

wp transient delete --expired

Когда допустимо полное удаление Transients

Полное удаление применяют во время диагностики, после изменения конфигурации кэширования, перед миграцией или когда требуется принудительно перестроить временные данные. Команда удаляет все transients, а не только уже устаревшие:

При этом сайт не теряет постоянные настройки WordPress, но плагины и тема должны создать кэш заново. Первые запросы могут требовать больше ресурсов: обращаться к внешним API, выполнять сложные SQL-запросы или генерировать данные для страниц.

Не запускайте полную очистку по фиксированному расписанию cron без анализа последствий. Если удалять кэш каждый час или каждый день, система будет постоянно работать в режиме перестроения, а не использовать уже подготовленные значения. Это может увеличить нагрузку на PHP, MySQL и сторонние API.

• используйте команду только после оценки последствий для сайта;
• не выполняйте её одновременно с крупными импортами, рассылками или пиковыми кампаниями;
• после очистки следите за ошибками, временем ответа и количеством запросов к внешним сервисам.

wp transient delete --all

Что меняется при использовании Redis или другого object cache

Если на сервере настроен Redis, Memcached или другой постоянный объектный кэш, transients могут обрабатываться иначе, чем в стандартной схеме с хранением только в MySQL. Часть данных может находиться в объектном кэше, а база данных может не содержать полной картины.

Команда wp transient delete работает через API WordPress, поэтому это более безопасный вариант, чем ручная очистка таблиц. Однако конкретное поведение зависит от реализации object cache и конфигурации плагина. Не следует автоматически очищать весь Redis командой вроде FLUSHALL: это может удалить кэш других сайтов, сервисов или приложений на том же сервере.

Если после удаления transients значения продолжают возвращаться, проверьте настройки object cache, префиксы ключей и логи. Иногда старые данные остаются в отдельном слое кэширования, а иногда плагин создаёт их заново во время первого запроса.

• уточните, подключён ли постоянный объектный кэш;
• не очищайте весь Redis без подтверждения границ конкретного сайта;
• проверьте, не работают ли параллельно кэш страниц, CDN или кэш на уровне прокси;
• если результат отличается от ожидаемого, проанализируйте логи PHP и Redis.

wp plugin list --status=active
wp transient list --format=count

Проверка результата и поиск причины повторного накопления

Очистка transients не устраняет причину их появления. Если после процедуры база снова быстро увеличивается, найдите плагин или тему, которые создают эти записи. Полезными признаками могут быть одинаковый префикс ключей, большое количество уникальных названий и постоянное создание записей с коротким сроком действия.

Проверьте журнал PHP на наличие ошибок тайм-аутов, проблем с API и повторных запросов. Для магазинов и сайтов с внешними интеграциями отдельно контролируйте лимиты API: после полной очистки большое количество одновременных посетителей может вызвать волну одинаковых запросов.

Результат следует оценивать не только по количеству удалённых записей. Важнее стабильность функций сайта, время ответа, нагрузка на PHP и базу данных, количество ошибок и скорость повторного заполнения кэша.

• сравните состояние сайта до и после очистки;
• проверьте страницы, использующие внешние интеграции;
• посмотрите, не увеличилось ли количество одинаковых запросов после сброса кэша;
• если transients возвращаются слишком быстро, проверьте код или настройки соответствующего плагина.

Типичные ошибки при очистке

Самая распространённая ошибка — выполнить полную очистку вместо удаления только устаревших значений. Для обычного обслуживания начинайте с --expired, а --all оставляйте для обоснованных случаев.

Вторая ошибка — ожидать мгновенного ускорения сайта. Если проблема связана с медленным плагином, неоптимальным запросом или перегруженным API, удаление transients лишь уберёт кэш и может временно увеличить нагрузку.

Третья ошибка — настроить регулярный cron, который безусловно удаляет все transients. Очистку устаревших данных можно автоматизировать, но даже в этом случае необходимо контролировать эффект и не запускать процесс чаще, чем оправдывает фактическое накопление.

• не используйте прямой DELETE в wp_options как первый метод;
• не очищайте весь object cache, не понимая его границ;
• не игнорируйте резервные копии и журналы;
• не оценивайте оптимизацию только по размеру таблицы wp_options.