Как уменьшить размер базы данных WordPress и убрать лишние записи

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

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

С чего начать: что именно раздувает базу

В WordPress база данных состоит не только из публикаций и пользователей. Основной «мусор» обычно сидит в нескольких местах:

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

Если база выросла резко, сначала проверьте, не оставил ли какой-то плагин собственные таблицы. Если рост постепенный, чаще всего виноваты ревизии, комментарии и транзиенты.

Что можно удалить сразу, а что лучше проверить отдельно

Безопаснее всего начинать с того, что WordPress умеет пересоздавать или что не влияет на содержимое сайта.

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

Как очистить базу WordPress без риска потерять важные данные

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

Если вы используете Clearfy Pro, в нём есть функции для удаления ревизий, мусора и части служебных данных. Это удобно, когда нужно привести сайт в порядок без ручного редактирования базы. Но даже при использовании плагина сначала проверьте, какие именно типы записей он предлагает удалить.

Практический порядок такой:

1. Сделайте резервную копию базы данных.
2. Проверьте, есть ли на сайте важные плагины с собственными таблицами или логами.
3. Удалите ревизии и автосохранения.
4. Очистите спам, корзину комментариев и старые временные данные.
5. Проверьте, не остались ли неиспользуемые таблицы от удалённых плагинов.

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

Ревизии: самый частый источник лишнего объёма

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

Удаление старых ревизий обычно безопасно, если у вас уже есть актуальная версия записи и резервная копия базы. После очистки останется текущая версия контента, а старые промежуточные сохранения исчезнут.

Если ревизий слишком много и они продолжают плодиться, можно ограничить их количество на уровне конфигурации WordPress. Для этого в wp-config.php добавляют константу WP_POST_REVISIONS. Например, чтобы оставить только три ревизии на запись:

define( 'WP_POST_REVISIONS', 3 );

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

Транзиенты и кэш: когда их можно удалять

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

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

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

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

Комментарии — ещё одна типичная причина разрастания базы. Даже если спам не публикуется на сайте, он может копиться в таблице комментариев и метаданных. То же относится к корзине: записи вроде бы удалены, но физически ещё лежат в базе.

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

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

Старые данные плагинов: что делать с хвостами после удаления

Самая неприятная часть — данные, которые оставляют удалённые плагины. WordPress не всегда удаляет их автоматически. В результате в базе остаются опции, таблицы, метаданные и логи, которые уже никому не нужны.

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

Обычно стоит смотреть на:

• таблицы с нестандартным префиксом, которые явно принадлежат плагину;
• записи в таблице wp_options с названием плагина;
• мета-данные в wp_postmeta, wp_usermeta и wp_commentmeta;
• логи, кэш и временные таблицы, если плагин их создавал.

Если вы не уверены, что именно можно удалить, лучше сначала сделать дамп базы и проверить список таблиц через phpMyAdmin или другой клиент. Для небольшого сайта это безопаснее, чем пытаться «почистить всё подряд».

Как проверить, что база действительно стала легче

После очистки не ограничивайтесь ощущением, что «админка вроде стала быстрее». Проверьте результат по двум признакам: размер базы и поведение сайта.

Размер можно посмотреть в панели хостинга, в phpMyAdmin или через инструменты самого плагина, если он показывает статистику до и после очистки. Сравнивать лучше не только общий объём, но и размер отдельных таблиц: так проще понять, что именно раздувало базу.

По работе сайта смотрите на следующие вещи:

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

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

Что стоит сделать после чистки, чтобы база не разрасталась снова

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

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

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

В итоге задача сводится не к «магической оптимизации», а к нормальной гигиене базы: убрать то, что уже не нужно, ограничить повторное накопление мусора и не трогать рабочие данные без понимания, за что они отвечают. Тогда админка становится легче, а резервные копии — меньше и быстрее.