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