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

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

Ниже — практичный порядок действий: от быстрой диагностики до очистки и проверки результата. Он подходит для обычного сайта на WordPress без глубокой настройки сервера и без риска удалить контент, который ещё нужен.

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

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

Чаще всего разрастание дают такие категории:

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

Важно понимать: большой размер базы сам по себе не всегда проблема. Если сайт активно работает и в базе много полезных данных, её объём может быть нормальным. Чистить нужно не «всё подряд», а именно мусор и устаревшие записи.

Перед очисткой сделайте резервную копию

Любая работа с базой данных должна начинаться с бэкапа. Это не формальность: если удалить не то, восстановить запись из админки WordPress уже не получится. Особенно осторожно нужно быть с ручными SQL-запросами и массовой очисткой через плагины.

Минимум, который стоит сделать:

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

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

Проверьте, что можно удалить без риска

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

Очистите корзину и спам

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

Для комментариев это особенно полезно: спам не только занимает место, но и раздувает таблицу комментариев и связанные метаданные.

Удалите старые черновики и ненужные ревизии

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

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

Как безопасно убрать ревизии и автосохранения

Ревизии и автосохранения обычно занимают много места в таблице wp_posts. Это один из самых частых источников раздувания базы. Есть два рабочих пути: через плагин или через SQL/инструменты хостинга. Для большинства владельцев сайта безопаснее начать с плагина, если он умеет удалять именно ревизии, а не «всё подряд».

Если вы работаете через phpMyAdmin или аналогичную панель, перед любым запросом убедитесь, что у таблиц префикс не отличается от стандартного wp_. На реальных сайтах префикс часто другой.

Для удаления ревизий можно использовать такой запрос:

DELETE FROM wp_posts WHERE post_type = 'revision';

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

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

Временные данные плагинов: что можно чистить, а что нет

Плагины часто создают временные записи в таблице wp_options и других таблицах. Это могут быть кэши, временные токены, служебные флаги, данные синхронизации и результаты фоновых задач. Часть из них WordPress и плагины должны удалять сами, но на практике мусор остаётся.

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

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

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

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

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

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

Оптимизация таблиц после удаления мусора

После массового удаления данных размер базы на диске не всегда уменьшается сразу. Таблицы могут сохранить «пустое место», которое MySQL/MariaDB не возвращает автоматически. Поэтому после очистки имеет смысл выполнить оптимизацию таблиц.

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

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

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

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

• Посмотрите размер базы в панели хостинга или в phpMyAdmin до и после очистки.
• Проверьте, открываются ли записи, страницы, комментарии и формы без ошибок.
• Если чистили ревизии, убедитесь, что редактор WordPress по-прежнему сохраняет новые версии.
• Если удаляли временные данные плагинов, проверьте его основные функции: кэш, формы, интеграции, рассылки, импорты.

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

Что не стоит удалять без проверки

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

Не удаляйте без понимания:

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

Если сайт клиентский или рабочий, лучше чистить базу поэтапно: сначала очевидный мусор, потом ревизии, затем временные данные. Такой подход почти всегда безопаснее, чем одна большая «генеральная уборка».

Если вам нужен более удобный способ регулярно убирать ревизии, спам и служебный мусор без ручных запросов, стоит смотреть в сторону инструментов обслуживания базы и очистки лишних данных. Один из таких вариантов — Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином принцип остаётся тем же: сначала резервная копия, потом выборочная очистка, затем проверка сайта.

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