Если WordPress начал заметно тормозить, а база данных разрослась без очевидной причины, транзиенты — один из первых кандидатов на проверку. Это временные данные, которые WordPress и плагины сохраняют для ускорения работы: кэш запросов, результаты API, служебные значения. Обычно они должны удаляться сами, но на практике часть записей остается в базе дольше, чем нужно, особенно если сайт активно использует плагины, внешние API или кэширование.
Очистка транзиентов не лечит все проблемы с производительностью, но часто быстро убирает мусор из таблиц базы и помогает вернуть нормальную работу админки и фронтенда. Ниже — как понять, что именно можно удалить, и как сделать это безопасно.
Что такое транзиенты и почему они мешают
Транзиенты в WordPress — это временные значения, которые хранятся либо в таблице wp_options, либо в объектном кэше, если он подключен. У каждого транзиента есть срок жизни. После его истечения значение считается устаревшим и должно быть пересоздано при следующем обращении.
Проблема в том, что устаревшие записи не всегда исчезают сразу. Если сайт давно работает без регулярной очистки, в базе накапливаются тысячи строк вида _transient_... и _transient_timeout_.... Сами по себе они не всегда критичны, но на сайтах с большой базой, слабым хостингом или неудачной конфигурацией это начинает влиять на скорость запросов к базе и на удобство работы в админке.
Особенно часто это видно после:
- массовой установки и удаления плагинов;
- частых обращений к внешним API;
- долгой работы сайта без обслуживания базы;
- ошибок в плагинах, которые создают транзиенты, но не чистят их корректно.
Какие транзиенты можно удалять без риска
Безопаснее всего удалять именно устаревшие транзиенты, то есть те, у которых истек срок действия. Это временные данные, и WordPress при необходимости создаст их заново. Для сайта это штатная операция.
Удаление всех транзиентов тоже обычно не ломает сайт, но есть нюанс: после такой очистки часть страниц и запросов может на короткое время работать медленнее, пока кэш не заполнится заново. Это не ошибка, а нормальный эффект после сброса временных данных.
Не стоит вручную удалять отдельные записи в базе, если вы не понимаете, к какому плагину они относятся. Лучше использовать штатные способы очистки: через WordPress, плагин или WP-CLI. Так меньше шанс задеть служебные данные, которые плагин ожидает увидеть в определенном формате.
Самый простой способ: очистить транзиенты через админку
Если нужен быстрый и безопасный вариант без командной строки, используйте плагин для обслуживания базы. Подойдут инструменты, которые умеют удалять устаревшие транзиенты и, при необходимости, все транзиенты целиком. Это удобно, если у вас нет доступа к SSH или вы не хотите работать напрямую с базой.
Перед очисткой сделайте резервную копию базы данных. Это не формальность: если на сайте есть нестандартный плагин кэширования или самописный код, лучше иметь возможность откатиться.
Дальше логика обычно такая:
- Откройте раздел обслуживания базы или очистки данных в плагине.
- Найдите пункт, связанный с transient-данными.
- Сначала удалите устаревшие транзиенты.
- Если база все еще сильно раздута, можно отдельно удалить все транзиенты, но только после проверки, что сайт не использует их как часть критичной логики.
После очистки обновите несколько страниц сайта и проверьте, не появились ли ошибки в админке или на фронтенде. Если все работает, значит очистка прошла нормально.
Очистка транзиентов через WP-CLI
Если у вас есть SSH-доступ и установлен WP-CLI, это самый удобный способ для регулярной очистки. Команды работают быстро и не требуют захода в админку.
Сначала проверьте, доступен ли WP-CLI в окружении. Затем выполните очистку устаревших транзиентов:
wp transient delete --expiredЭта команда удаляет только просроченные значения. Она подходит для планового обслуживания и обычно безопасна даже на живом сайте.
Если нужно удалить все транзиенты, используйте:
wp transient delete --allС этой командой нужно быть осторожнее: после нее сайт может временно чаще обращаться к внешним сервисам и базе, потому что кэш придется создавать заново. Для большого проекта лучше запускать ее в спокойное время, когда нагрузка ниже.
Если хотите сначала посмотреть, что именно хранится в транзиентах, можно вывести список:
wp transient listЭто полезно для диагностики: если вы видите огромное количество записей от одного и того же плагина, проблема может быть не в WordPress как таковом, а в конкретном расширении, которое слишком активно пишет временные данные.
Удаление транзиентов кодом, если нет доступа к плагинам и SSH
Иногда проще временно добавить небольшой код в тему или в собственный плагин. Этот вариант подходит, если нужно один раз очистить устаревшие транзиенты, а потом убрать код. Не оставляйте такой код в рабочей теме надолго без необходимости.
Для удаления только просроченных транзиентов можно использовать встроенные функции WordPress:
if ( function_exists( 'delete_expired_transients' ) ) {
delete_expired_transients();
}Функция delete_expired_transients() удаляет только устаревшие записи. Это безопаснее, чем массово чистить все подряд. Если вам нужно именно разовое обслуживание, этот вариант обычно достаточен.
Если требуется удалить конкретный транзиент, используйте его имя:
delete_transient( 'my_transient_name' );Такой способ полезен, когда вы точно знаете, какой плагин или кусок кода создает проблемный transient. Например, если внешний API изменил ответ, а старая запись мешает получить свежие данные.
Для удаления всех транзиентов через код есть функция delete_transient() только для одного ключа, поэтому массовую очистку лучше делать через WP-CLI или плагин обслуживания. Вручную писать SQL-запросы к базе можно, но это уже рискованнее: легко удалить лишнее или задеть данные, которые используются в другом контексте.
Как понять, что транзиенты действительно были причиной тормозов
После очистки не ждите мгновенного чуда на всех сайтах. Транзиенты — это только один слой кэширования. Если проблема была именно в разросшейся базе, вы обычно заметите:
- быстрее открывается админка;
- уменьшается время ответа на отдельных страницах;
- в базе становится меньше мусорных записей;
- исчезают старые данные, которые мешали обновлению кэша.
Проверить результат можно двумя способами. Первый — посмотреть размер таблицы wp_options в phpMyAdmin или через панель хостинга. Второй — снова вывести список транзиентов через WP-CLI и убедиться, что устаревших записей стало меньше или они удалены.
Если после очистки сайт не ускорился, причина, скорее всего, в другом: тяжелые запросы, слабый хостинг, проблемы с плагинами, отсутствие полноценного объектного кэша, перегруженная тема. В таком случае транзиенты были лишь сопутствующим мусором, а не основной причиной.
Что делать, чтобы транзиенты не разрастались снова
Полностью запретить транзиенты не нужно — они полезны. Задача в том, чтобы они не превращались в свалку. Для этого достаточно нескольких практических действий.
- Регулярно чистить устаревшие транзиенты, если сайт активно использует кэш и внешние сервисы.
- Следить за плагинами, которые часто обращаются к API и создают много временных данных.
- Не держать в активной теме самописный код, который пишет transient-данные без срока жизни или без логики очистки.
- Периодически проверять размер таблицы
wp_options, особенно на старых сайтах.
Если у вас есть системный объектный кэш, часть transient-данных может храниться не в базе, а в памяти. Тогда очистка базы не всегда покажет весь эффект, потому что данные живут в другом слое. Это зависит от конфигурации сайта, хостинга и используемого кэш-решения.
Для сайтов, где обслуживание базы нужно делать регулярно, удобно использовать инструменты, которые умеют чистить мусор и служебные записи без ручного SQL. Если вам нужен именно такой набор задач, можно посмотреть на Clearfy Pro: он решает часть типичных задач по чистке сайта и обслуживанию WordPress, но использовать его стоит только если вам действительно нужен комплексный инструмент, а не разовая очистка транзиентов.
Если нужен короткий рабочий план, он такой: сначала удалите устаревшие транзиенты, затем проверьте сайт, после этого при необходимости очистите все transient-записи и только потом ищите более глубокую причину тормозов. Такой порядок безопаснее, чем сразу лезть в базу и удалять все подряд.