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

Автор: Алексей Крылов | Опубликовано: 20.10.2026

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

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

Что обычно раздувает базу WordPress

В большинстве проектов рост базы дают несколько типичных источников:

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

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

С чего начать, чтобы не потерять данные

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

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

После этого полезно понять, что именно занимает место. В phpMyAdmin можно посмотреть размер таблиц: обычно самые большие — это wp_posts, wp_postmeta, wp_options, wp_comments и таблицы плагинов. Если база раздута, но сайт небольшой, почти всегда виноваты ревизии, автосохранения, транзиенты или старые данные плагинов.

Что можно удалять без риска для сайта

Есть данные, которые обычно можно чистить безболезненно, если вы понимаете их назначение.

Ревизии записей и страниц

WordPress хранит версии изменений постов и страниц. Это удобно, но на сайтах с активной редактурой количество ревизий быстро растёт. Удаление старых ревизий обычно безопасно: текущая версия записи остаётся, а история редактирования сокращается.

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

define( 'WP_POST_REVISIONS', 5 );

Число можно подобрать под ваш рабочий процесс. Для новостного сайта или проекта с несколькими редакторами 3–5 ревизий обычно достаточно. Полное отключение ревизий возможно, но я бы не советовал делать это без причины: при ошибке в тексте они часто спасают время.

Автосохранения

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

Транзиенты

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

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

Спам и корзина

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

На сайтах с большим потоком комментариев это даёт заметный эффект, но ещё важнее — снижает количество мусора в таблицах комментариев и метаданных.

Что требует осторожности

Есть данные, которые нельзя удалять «на глаз». Здесь лучше сначала понять, к какому плагину или части сайта они относятся.

Постметаданные и пользовательские поля

Таблица wp_postmeta часто раздувается сильнее самой таблицы записей. Но удалять из неё строки вручную без понимания структуры сайта опасно: там могут храниться SEO-поля, данные конструктора, настройки шаблона, параметры товаров, галереи и многое другое.

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

Таблицы плагинов

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

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

Опции в таблице wp_options

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

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

Как чистить базу на практике

Есть три рабочих пути: через плагин, через phpMyAdmin и через WP-CLI. Выбор зависит от доступа к серверу и вашего опыта.

Через плагин — самый безопасный вариант для большинства сайтов

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

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

Плюс плагина в том, что он обычно безопаснее ручной чистки для неразборчивого пользователя. Минус — нужно внимательно смотреть, что именно отмечено к удалению, и не запускать всё подряд без проверки.

Через phpMyAdmin — если нужен точечный контроль

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

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

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

Через WP-CLI — удобно для больших сайтов

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

Но WP-CLI тоже требует аккуратности: команды должны соответствовать версии WordPress и установленным плагинам. Если вы не используете командную строку регулярно, не начинайте с неё без теста на копии сайта.

Как уменьшить базу не только один раз, но и надолго

Разовая чистка помогает, но если ничего не менять в процессе работы сайта, база снова начнёт расти. Чтобы этого не произошло слишком быстро, имеет смысл ограничить источник мусора.

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

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

Как проверить, что очистка сработала

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

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

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

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