Если админка WordPress стала заметно медленнее, резервные копии раздулись, а в базе копятся следы старых плагинов и удалённого контента, проблему обычно решают не «ускорением сайта», а чисткой базы данных. В WordPress это особенно важно: со временем в базе накапливаются ревизии записей, автосохранения, спам-комментарии, временные записи, транзиенты, служебные данные плагинов и мусор от удалённых расширений.
Сразу оговорюсь: безопасная очистка базы — это не удаление всего подряд. Сначала нужно понять, что именно занимает место, затем убрать только то, что действительно больше не нужно, и только после этого при необходимости оптимизировать таблицы. Такой подход уменьшает риск потерять важные данные и не сломать сайт.
С чего начать: что именно раздувает базу WordPress
В типичной установке WordPress основной объём занимают несколько групп данных:
- ревизии записей — старые версии постов и страниц;
- автосохранения — промежуточные черновики редактора;
- спам и корзина комментариев;
- транзиенты — временные кэши, которые иногда не очищаются вовремя;
- метаданные записей, пользователей и комментариев;
- служебные записи плагинов, которые остаются после удаления расширения;
- старые таблицы от давно удалённых плагинов;
- лог-таблицы, если плагин пишет много технических событий.
Не все эти данные вредны. Например, ревизии полезны, пока вы активно редактируете контент. Но если на сайте тысячи записей, а редакторы сохраняют каждую правку, база быстро растёт без заметной пользы.
Перед очисткой сделайте резервную копию
Это тот шаг, который нельзя пропускать. Любая работа с базой данных должна начинаться с бэкапа, даже если вы собираетесь удалить только «мусор». Ошибка в запросе, неудачный плагин очистки или удаление нужной служебной записи могут привести к потере контента, настроек или части функциональности.
Минимум нужен полный бэкап базы данных. Если хостинг позволяет, лучше сохранить и файлы сайта. Для проверки восстановления достаточно убедиться, что дамп можно скачать и что у вас есть доступ к панели хостинга или инструменту восстановления.
Если сайт рабочий и важный, не делайте очистку в часы пик. После бэкапа полезно открыть сайт и админку в обычном режиме, чтобы понимать исходное состояние и потом сравнить результат.
Какие записи можно удалять безболезненно, а какие — только после проверки
Самая частая ошибка — чистить базу по принципу «всё старое удалить». На практике безопаснее разделить данные на две группы.
| Можно удалять почти всегда | Требует проверки перед удалением |
|---|---|
| Спам-комментарии и корзина комментариев | Ревизии записей, если редакторы используют историю правок |
| Автосохранения старых черновиков | Транзиенты, если на сайте есть плагины, которые используют их нестандартно |
| Временные данные плагинов, если плагин уже удалён | Метаданные записей и пользователей |
| Старые логи, если они не нужны для диагностики | Таблицы плагинов, если неясно, к какому расширению они относятся |
Если сомневаетесь, сначала выясните источник данных. В базе WordPress почти всё связано с конкретным плагином или типом контента, и удаление «на глаз» здесь плохая идея.
Очистка базы через админку: когда этого достаточно
Если база разрослась не критично, начать можно с простых действий без доступа к SQL.
Удалите спам и корзину
В разделе комментариев очистите спам и корзину. Если на сайте много пользовательской активности, это часто даёт заметный эффект без риска для контента.
Проверьте корзину записей и страниц
Удалённые записи и страницы не исчезают сразу. Если в корзине накопились старые материалы, очистите её вручную. Это особенно полезно после массовых правок и переноса контента.
Сократите количество ревизий
Ревизии можно удалить, если вы уверены, что не будете откатываться к старым версиям. Но здесь важно не путать удаление старых ревизий с отключением ревизий вообще. Если сайт регулярно редактируют несколько человек, полностью убирать ревизии не всегда разумно.
После такой чистки база обычно уменьшается не радикально, но уже становится легче для резервного копирования и обслуживания.
Как безопасно убрать ревизии, автосохранения и транзиенты
Для более глубокой очистки обычно используют плагин обслуживания базы или SQL-запросы. Если вы не работаете с базой напрямую, плагин безопаснее: он показывает, что именно будет удалено, и обычно не трогает критичные таблицы.
Но даже с плагином нужно понимать логику очистки:
- ревизии удаляйте только после проверки, что текущие версии записей сохранены;
- автосохранения можно чистить, если это старые промежуточные данные, а не активная работа редактора;
- транзиенты обычно можно удалить, потому что WordPress и плагины создают их заново;
- временные кэши плагинов удаляйте только если знаете, что они действительно не нужны.
Если вы работаете через SQL, делайте это только после бэкапа и только понимая, какие таблицы используются на сайте. В WordPress ревизии хранятся в таблице wp_posts, а связанная служебная информация — в wp_postmeta. Префикс таблиц может отличаться, если при установке он был изменён.
Пример удаления старых ревизий через SQL может выглядеть так:
DELETE FROM wp_posts WHERE post_type = 'revision';Это рабочий запрос, но применять его стоит только если вы осознанно решили убрать все ревизии. На живом контентном сайте чаще разумнее сначала ограничить количество будущих ревизий, а не удалять всё подряд.
Транзиенты обычно удаляют из таблицы wp_options. Но здесь тоже важно не перепутать служебные временные значения WordPress с данными плагинов. Если вы не уверены, лучше использовать инструмент, который показывает список транзиентов перед удалением.
Что делать с таблицами и данными удалённых плагинов
После деинсталляции плагина в базе нередко остаются его таблицы и настройки. Это частая причина лишнего объёма: сам плагин уже не используется, а данные продолжают лежать в базе и раздувать бэкапы.
Проверять нужно в два этапа:
- Убедиться, что плагин действительно не нужен и не используется на сайте.
- Посмотреть, какие таблицы и опции он оставил после удаления.
Если плагин удалён давно и вы точно не планируете его возвращать, его таблицы можно убрать вручную. Но сначала проверьте, не использует ли их другой плагин или тема. На практике это особенно важно для расширений, которые хранят настройки в отдельных таблицах, а не только в wp_options.
Если вы не знаете назначение таблицы, не удаляйте её вслепую. Лучше сначала найти по названию плагина или проверить документацию расширения. Это дешевле, чем потом восстанавливать сайт из бэкапа.
Как уменьшить размер таблиц после удаления мусора
После очистки базы размер таблиц на диске не всегда уменьшается сразу. В MySQL и MariaDB место часто освобождается не автоматически, а после оптимизации таблиц. Поэтому после удаления большого объёма данных имеет смысл выполнить оптимизацию.
В WordPress это можно сделать через инструменты хостинга, phpMyAdmin или специализированный плагин. Если таблиц много, а база крупная, оптимизация может занять время и временно нагрузить сервер. На слабом хостинге лучше делать это в часы минимальной нагрузки.
Смысл оптимизации простой: удалённые строки перестают занимать место внутри таблицы, а структура данных уплотняется. Это особенно заметно после чистки ревизий, спама и логов.
Но не стоит ждать чудес. Если база большая из-за нормального объёма контента и метаданных, оптимизация не сделает её маленькой. Она лишь убирает лишнее пространство, которое осталось после удаления записей.
Как проверить, что очистка действительно помогла
После работы стоит проверить не только размер базы, но и поведение сайта.
- Откройте админку и убедитесь, что разделы записей, комментариев и настроек работают как раньше.
- Проверьте страницы, которые активно редактировались, чтобы не пропали нужные версии.
- Посмотрите размер базы в панели хостинга или в phpMyAdmin до и после очистки.
- Сделайте тестовый бэкап и сравните его размер с предыдущим.
Если после чистки админка стала заметно быстрее, а резервные копии уменьшились, значит вы убрали именно тот мусор, который мешал. Если улучшения почти нет, причина может быть не в базе, а в тяжёлых запросах темы, плагинах, медленном диске хостинга или отсутствии объектного кэша.
Как не превратить чистку базы в новую проблему
Уменьшать базу WordPress лучше не разовой «генеральной уборкой», а регулярным обслуживанием. Для этого достаточно нескольких правил:
- не хранить бесконечное количество ревизий, если сайт активно редактируется;
- периодически очищать спам, корзину и старые автосохранения;
- удалять неиспользуемые плагины вместе с их данными, если вы уверены, что они больше не нужны;
- не ставить плагины, которые пишут в базу большие логи без необходимости;
- перед любыми массовыми изменениями делать резервную копию.
Если нужна более удобная и регулярная чистка без ручной работы с таблицами, можно использовать инструменты обслуживания базы и оптимизации сайта. В экосистеме WordPress для этого подходят решения, которые умеют удалять дубли, мусор и служебные данные аккуратно, без вмешательства в контент. Но принцип остаётся тем же: сначала бэкап, потом проверка, потом удаление только лишнего.
Когда база WordPress раздута, не пытайтесь лечить всё одной кнопкой. Сначала уберите очевидный мусор, затем проверьте таблицы удалённых плагинов, после этого при необходимости оптимизируйте структуру. Такой порядок безопаснее и обычно даёт лучший результат, чем агрессивная чистка без понимания, что именно хранится в базе.