Если база данных WordPress разрослась, сайт обычно начинает тормозить не из-за одного большого файла, а из-за накопленного мусора: ревизий записей, временных данных, старых сессий, спам-комментариев, транзиентов и следов удалённых плагинов. Чистить это можно, но только по порядку: сначала понять, что именно занимает место, потом убрать безопасные данные, и лишь затем трогать более рискованные вещи.
Ниже — практичный план, который помогает уменьшить размер базы без удаления контента и без лишнего риска сломать сайт.
С чего начать: что именно раздувает базу
В WordPress чаще всего разрастаются не сами записи и страницы, а служебные данные в таблицах базы. Самые типичные источники:
- ревизии записей и страниц;
- автосохранения;
- временные данные WordPress и плагинов, то есть transient-значения;
- спам и корзина комментариев;
- старые метаданные после удалённых плагинов;
- таблицы, которые создали плагины и не удалили после деинсталляции;
- логирование и кэш внутри базы, если плагин хранит его там.
Если вы не уверены, что именно разрослось, сначала посмотрите размер таблиц в phpMyAdmin или в панели хостинга. Обычно сразу видно, какие таблицы сильно выбиваются по объёму: это могут быть wp_posts, wp_postmeta, wp_options, wp_comments и таблицы сторонних плагинов. По одной только таблице wp_posts нельзя делать вывод, что проблема в контенте: очень часто там лежат ревизии и автосохранения.
Что можно удалить безопасно в первую очередь
Самая безопасная очистка — это то, что WordPress и так считает временным или промежуточным. Здесь риск минимальный, если не путать системные данные с нужным контентом.
Ревизии и автосохранения
Ревизии — это сохранённые версии записей и страниц. Они полезны, но на активном сайте их может накопиться очень много, особенно если редакторы часто правят длинные материалы. Автосохранения тоже занимают место, хотя по отдельности они небольшие.
Удалять ревизии можно, если вы уверены, что не будете возвращаться к старым версиям материалов. Для обычного сайта это безопасная операция, но перед чисткой всё равно стоит сделать резервную копию базы.
Если нужен ручной способ через SQL, сначала проверьте, что префикс таблиц у вас действительно wp_. На многих сайтах он другой. Запрос удаляет только ревизии:
DELETE FROM wp_posts WHERE post_type = 'revision';Автосохранения обычно лежат в той же таблице как отдельные записи, и после удаления ревизий они тоже часто уходят, но не всегда. Если хотите проверить объём мусора до удаления, сначала выполните выборку:
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';Если число большое, очистка даст заметный эффект по размеру таблицы wp_posts.
Транзиенты и временные данные
Транзиенты — это временные значения, которые WordPress и плагины используют для кэша, временных настроек и промежуточных результатов. Часть из них должна удаляться автоматически, но на практике просроченные записи нередко остаются в базе.
Удалять просроченные транзиенты обычно безопасно. Опасно только путать их с постоянными настройками плагинов. Если вы чистите вручную, удаляйте именно просроченные transient-значения, а не всё подряд в wp_options.
В WordPress есть встроенная команда WP-CLI для очистки транзиентов, но она доступна не на каждом хостинге. Если у вас есть доступ к WP-CLI, это удобный вариант:
wp transient delete --expiredЕсли WP-CLI недоступен, можно использовать плагин для очистки базы или сделать это через phpMyAdmin, но в этом случае важно не удалять записи наугад из wp_options. Там лежат и критически важные настройки сайта.
Спам, корзина и старые комментарии
Если на сайте включены комментарии, база может разрастаться из-за спама и неочищенной корзины. Это не самый большой источник мусора, но на старых сайтах он заметен.
Сначала очистите спам и корзину через админку WordPress. Это безопаснее, чем удалять записи напрямую из базы, потому что WordPress сам уберёт связанные данные корректно.
Как убрать мусор после плагинов и не сломать сайт
Самая опасная часть очистки — не ревизии и не транзиенты, а следы удалённых плагинов. Здесь легко удалить лишнее, но ещё легче задеть нужные настройки.
После деинсталляции плагин может оставить:
- свои таблицы в базе;
- записи в
wp_options; - метаданные в
wp_postmetaиwp_usermeta; - кэш, логи и служебные записи.
Если плагин удалён давно и вы точно не используете его данные, оставшиеся таблицы можно удалить вручную. Но делать это нужно только после проверки, что таблица действительно принадлежит ненужному плагину. Название таблицы обычно подсказывает источник, например по префиксу или по названию плагина.
С настройками в wp_options осторожнее всего. Там хранятся не только мусорные записи, но и параметры темы, активных плагинов, постоянные настройки сайта, кэш и служебные флаги. Если вы не уверены, что конкретная опция относится к удалённому плагину, лучше не трогать её вручную.
Практически безопасный подход такой: сначала удалите плагин штатно, затем проверьте, остались ли его таблицы, и только после этого решайте, нужны ли они. Если плагин был крупный и давно использовался, перед удалением таблиц стоит сделать отдельную копию базы.
Когда имеет смысл использовать плагин для очистки базы
Если вы не хотите работать с SQL и phpMyAdmin, проще использовать плагин, который умеет чистить ревизии, транзиенты, спам и служебный мусор. Это особенно удобно, когда сайт ведётся без постоянного участия разработчика.
Но здесь есть важное ограничение: не каждый плагин для оптимизации базы одинаково безопасен. Перед запуском очистки проверьте, что он показывает, что именно будет удалено, и даёт возможность выбрать типы данных по отдельности. Если плагин предлагает «почистить всё» одной кнопкой без расшифровки, это плохой знак.
Для владельца сайта обычно лучше тот инструмент, который позволяет:
- отдельно удалить ревизии;
- отдельно очистить транзиенты;
- отдельно убрать спам и корзину;
- не трогать таблицы и опции без явного подтверждения.
Если вам нужен более широкий набор инструментов для чистки сайта и удаления дублей, можно посмотреть Clearfy Pro: Clearfy Pro. Он не заменяет внимательную проверку, но помогает убрать часть типового мусора без ручной работы с базой.
Порядок очистки, который обычно даёт лучший результат
Если нужен понятный и безопасный план, действуйте так:
- Сделайте резервную копию базы данных. Это обязательный шаг перед любой ручной чисткой.
- Посмотрите, какие таблицы занимают больше всего места.
- Удалите ревизии и автосохранения.
- Очистите просроченные транзиенты.
- Удалите спам и корзину комментариев.
- Проверьте удалённые плагины и их таблицы.
- Только после этого решайте, нужно ли вручную чистить отдельные записи в
wp_options,wp_postmetaили других таблицах.
Такой порядок важен: сначала вы убираете безопасный мусор, а уже потом переходите к данным, где выше риск задеть рабочие настройки.
Как проверить, что база действительно стала меньше
После очистки не ориентируйтесь только на ощущения. Проверьте результат по двум признакам: размер таблиц и поведение сайта.
Сначала откройте список таблиц в phpMyAdmin или панели хостинга и сравните размеры до и после. Если вы удаляли ревизии, заметнее всего должна уменьшиться wp_posts. Если чистили транзиенты и мусор в настройках, может уменьшиться wp_options. Если удаляли следы плагина, сократится его собственная таблица или несколько таблиц.
Затем откройте сайт и админку, проверьте сохранение записей, работу форм, комментариев и тех функций, которые могли зависеть от удалённого плагина. Если после чистки что-то перестало работать, значит, был удалён не только мусор, но и нужные данные. В этом случае помогает только резервная копия.
Что не стоит делать при очистке базы
Есть несколько типичных ошибок, из-за которых сайт потом приходится восстанавливать:
- удалять записи из
wp_optionsбез понимания, что они делают; - чистить таблицы плагинов, не убедившись, что плагин больше не нужен;
- удалять всё подряд из
wp_postmetaилиwp_usermetaвручную; - работать без резервной копии;
- использовать «оптимизаторы», которые не показывают, что именно удаляют.
Если задача — просто уменьшить размер базы WordPress, почти всегда достаточно убрать ревизии, транзиенты, спам и остатки удалённых плагинов. Глубокая ручная чистка нужна только тогда, когда вы точно понимаете структуру базы и видите конкретную проблему в таблицах.
В итоге самый безопасный путь выглядит так: сначала диагностика, потом очистка очевидного мусора, затем проверка таблиц плагинов и только после этого — точечная ручная работа. Такой подход даёт реальное уменьшение базы без лишнего риска для сайта.