Если WordPress начал заметно тормозить, а база данных разрослась без видимой причины, чаще всего проблема не в «тяжёлых» таблицах сама по себе, а в служебных данных: ревизиях записей, автосохранениях, удалённом спаме, корзине, временных записях плагинов и старых кэшированных значениях. Это всё можно чистить, но не вслепую: часть данных безопасно удаляется почти всегда, а часть зависит от того, как именно на сайте работают плагины и как давно не проводилась профилактика.
Ниже — практичный разбор того, что можно убрать без риска, что лучше проверять отдельно и как вообще не навредить сайту, пытаясь «ускорить базу».
Что именно раздувает базу WordPress
В WordPress мусор обычно лежит не в одном месте, а в нескольких таблицах. Чаще всего разрастаются wp_posts, wp_postmeta и wp_options. Это не значит, что сама структура базы плохая — просто туда попадают данные, которые уже не нужны для работы сайта, но продолжают храниться.
Самые типичные источники лишнего объёма:
- ревизии записей — сохранённые версии постов и страниц;
- автосохранения — временные черновики редактора;
- спам-комментарии и комментарии в корзине;
- удалённые записи и страницы, которые остались в корзине;
- временные данные плагинов и WordPress, включая устаревшие transient-значения;
- осиротевшие метаданные — записи в
postmeta,commentmeta,termmeta, которые ссылаются на уже удалённые объекты.
Если сайт давно живёт без чистки, именно эти данные часто дают основной прирост в размере базы, а не контент и не настройки темы.
Что можно удалять безопасно почти всегда
Есть несколько типов данных, которые обычно не нужны для работы сайта в текущем состоянии. Их можно чистить без заметного риска, если вы понимаете, что именно удаляете.
Ревизии записей
Ревизии нужны для отката текста к предыдущим версиям. Если на сайте много редактируемых страниц, они копятся очень быстро. Удаление старых ревизий обычно безопасно, но с оговоркой: вы потеряете возможность вернуться к более ранним версиям именно в базе. Если для проекта важна история правок, сначала убедитесь, что нужные версии не понадобятся.
На практике ревизии полезно чистить на сайтах, где контент уже опубликован и не редактируется каждый день. Это особенно актуально для лендингов, корпоративных страниц и старых статей.
Автосохранения
Автосохранения создаются редактором WordPress во время набора текста. Обычно они нужны только как страховка при сбое браузера или потере связи. Старые автосохранения можно удалять, потому что актуальная версия записи уже сохранена отдельно.
Если редакторы работают над длинными материалами, автосохранения могут быть полезны в процессе правки, но хранить их бесконечно смысла нет.
Спам и корзина комментариев
Спам-комментарии и комментарии в корзине не участвуют в работе сайта. Их можно удалять без сожаления. То же относится к записям и страницам в корзине: пока объект лежит в корзине, он всё ещё занимает место в базе.
Если на сайте включён поток комментариев, именно спам часто раздувает таблицы быстрее всего. Здесь важно не только удалить накопившееся, но и проверить антиспам-защиту, иначе мусор вернётся.
Временные данные и transient
WordPress и плагины используют временные значения для кэша и служебных задач. Часть из них автоматически истекает, но не всегда удаляется сразу. Такие записи обычно безопасно чистить, если речь идёт об устаревших transient-значениях, а не о данных, которые плагин использует прямо сейчас.
На сайтах с большим количеством плагинов именно transient-данные и служебный кэш нередко занимают неожиданно много места в wp_options.
С чего начать, чтобы не удалить лишнее
Перед чисткой базы сделайте резервную копию. Это не формальность: если плагин очистки сработает не так, как ожидалось, откат из бэкапа будет самым быстрым способом вернуть сайт в рабочее состояние. Для небольших сайтов достаточно дампа базы данных, для более серьёзных проектов лучше иметь полный бэкап файлов и базы.
Дальше проверьте три вещи:
- Есть ли на сайте редакторы, которым нужны старые ревизии для работы.
- Используются ли плагины, которые активно хранят данные в
wp_optionsили создают собственные таблицы. - Не включён ли на хостинге или в плагине кэш, который может маскировать результат чистки.
Если сайт рабочий и посещаемый, чистку лучше делать в спокойное время, а не в пик нагрузки. Сама операция обычно быстрая, но после неё полезно проверить админку, формы и страницы, которые зависят от плагинов.
Как очистить базу через админку WordPress
Самый простой путь — использовать плагин, который умеет удалять ревизии, автосохранения, спам и устаревшие служебные данные. Для владельца сайта это обычно безопаснее, чем вручную лезть в SQL, особенно если нет опыта работы с phpMyAdmin.
При выборе инструмента смотрите не на обещания «ускорить сайт в два раза», а на конкретные функции: удаление ревизий, очистка корзины, удаление спама, поиск осиротевших записей и очистка transient. Удобно, когда плагин показывает, сколько объектов будет удалено до подтверждения.
Если используете плагин для обслуживания базы, действуйте по такой схеме:
- Сделайте резервную копию.
- Откройте раздел очистки базы в админке.
- Отметьте только понятные категории мусора: ревизии, автосохранения, спам, корзину, устаревшие transient.
- Не запускайте массовое удаление неизвестных записей без понимания, что именно делает плагин.
- После очистки проверьте сайт и админку.
Если плагин предлагает оптимизацию таблиц, относитесь к ней как к отдельной операции. Для MySQL это штатная функция, но на больших базах и слабом хостинге она может занять время и кратковременно увеличить нагрузку.
Когда имеет смысл чистить базу вручную
Ручная чистка нужна не всем, но она полезна, если вы хотите точно понимать, что удаляете, или если плагин не справляется с конкретной задачей. Самый частый сценарий — удаление старых ревизий и автосохранений через SQL-запросы в phpMyAdmin или другом клиенте к MySQL.
Перед выполнением любых запросов ещё раз проверьте префикс таблиц. В примерах ниже используется стандартный wp_, но у вас он может быть другим.
Чтобы удалить ревизии, обычно используют такой запрос:
DELETE FROM wp_posts WHERE post_type = 'revision';Чтобы удалить автосохранения:
DELETE FROM wp_posts WHERE post_type = 'autosave';На практике автосохранения в WordPress чаще хранятся как специальные записи, и их поведение зависит от версии ядра и редактора. Поэтому перед удалением лучше убедиться, что вы действительно видите именно служебные записи, а не обычные черновики.
Для удаления спама и корзины комментариев обычно безопаснее использовать штатные механизмы админки, чем писать запросы вручную. Если всё же работаете через SQL, сначала проверьте, что удаляете именно комментарии со статусом спама или корзины, а не обычные отзывы и обсуждения.
Ручная чистка хороша тем, что вы контролируете процесс. Минус в том, что одна ошибка в запросе может удалить не то, что нужно. Если нет уверенности, лучше ограничиться админкой или проверенным плагином обслуживания базы.
Что делать с transient и мусором в wp_options
Таблица wp_options часто становится узким местом не из-за объёма как такового, а из-за накопления служебных записей и автозагружаемых опций. Здесь важно не перепутать полезные настройки сайта с временными данными.
Безопаснее всего удалять именно устаревшие transient-значения. Они предназначены для временного хранения и не должны быть вечными. Но если плагин использует transient как часть логики и ожидает их наличия, удаление может вызвать кратковременный пересчёт кэша или временную нагрузку на сервер. Это не поломка, а нормальная реакция на очистку.
Если вы видите, что wp_options раздута, проверьте ещё и автозагрузку опций. Слишком много autoload = yes замедляет каждый запрос к сайту, потому что WordPress подгружает такие значения почти на каждой странице. Это уже не просто вопрос размера базы, а вопрос скорости сайта. Но чистить здесь нужно аккуратно: удалять следует только очевидно ненужные записи, а не всё подряд.
Как понять, что чистка действительно помогла
После удаления мусора не стоит ждать магического ускорения. Эффект зависит от того, что именно было накоплено и насколько база была перегружена. На небольшом сайте разница может быть почти незаметной, а на проекте с тысячами ревизий и большим количеством спама — вполне ощутимой.
Проверять результат лучше в двух плоскостях:
- размер базы — он должен уменьшиться или хотя бы перестать расти из-за старого мусора;
- скорость админки и страниц — особенно если чистили
wp_optionsи transient; - стабильность сайта — формы, комментарии, редактор записей, поиск и кэш должны работать как раньше.
Если после чистки сайт стал заметно быстрее в админке, это хороший признак того, что база была перегружена служебными данными. Если разницы нет, значит узкое место, скорее всего, не в мусоре базы, а в теме, плагинах, кэше, запросах к базе или самом хостинге.
Что не стоит удалять без проверки
Главная ошибка при «генеральной уборке» базы — удалить всё, что выглядит подозрительно. В WordPress так делать нельзя. Не трогайте записи, если не понимаете их назначение, особенно в таблицах плагинов и в wp_options. Некоторые плагины хранят там лицензии, настройки форм, данные кэша и служебные флаги, без которых сайт может начать работать нестабильно.
Также не стоит массово удалять данные только потому, что база кажется большой. Размер сам по себе не проблема. Проблема — когда база содержит много ненужных записей, которые замедляют запросы, усложняют резервное копирование и увеличивают время обслуживания.
Если нужен более системный подход к обслуживанию WordPress-сайта, удобно использовать инструменты, которые умеют не только чистить базу, но и убирать дублирующиеся служебные данные, лишние элементы и следить за общим «весом» сайта. Например, для таких задач подходит Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpscan.ru&utm_medium=article&utm_campaign=kak-ochistit-bazu-dannyh-wordpress-ot-musora-revizii-avtosokhraneniya-spam-i-vremennye-dannye. Но даже с таким инструментом принцип остаётся тем же: сначала резервная копия, потом точечная очистка, затем проверка результата.
Если коротко, безопасная чистка базы WordPress сводится к четырём категориям: старые ревизии, автосохранения, спам и корзина, устаревшие временные данные. Именно они чаще всего раздувают базу без пользы для сайта. Удаляйте их регулярно, но не превращайте обслуживание в массовое стирание всего подряд — тогда база будет компактнее, а сайт обычно работает спокойнее и предсказуемее.