Если сайт на WordPress работает давно, база данных почти всегда разрастается за счет ревизий записей, временных данных, спам-комментариев, удаленных элементов и служебных записей от плагинов. Это не всегда критично, но со временем лишние данные начинают мешать: резервные копии становятся тяжелее, админка медленнее, а запросы к базе — дороже для хостинга. Очистить и оптимизировать базу можно без плагинов, если действовать аккуратно и понимать, что именно удаляется.
Самый безопасный подход такой: сначала сделать резервную копию, затем убрать очевидный мусор, после этого оптимизировать таблицы. Для большинства сайтов этого достаточно, чтобы база перестала раздуваться без риска сломать контент или настройки.
С чего начать, чтобы не потерять данные
Перед любой ручной чисткой базы нужно сделать полную резервную копию файлов и базы данных. Это не формальность: одна неверная команда в phpMyAdmin или в консоли может удалить не только мусор, но и нужные записи. Если у хостинга есть штатный бэкап, используйте его. Если есть доступ к панели управления, экспортируйте базу в SQL-файл. На рабочем сайте не стоит чистить базу «на глаз» без возможности отката.
Еще один практический момент: перед удалением данных полезно понять, что именно раздувает базу. В WordPress чаще всего это:
- ревизии записей и страниц;
- автосохранения черновиков;
- временные записи в таблице
wp_options; - спам и корзина комментариев;
- удаленные записи, страницы и медиафайлы;
- служебные данные плагинов, которые уже не используются.
Если сайт работает на нестандартном префиксе таблиц, вместо wp_ будет другой. В командах и SQL-запросах это нужно заменить на ваш реальный префикс.
Что можно удалить вручную без риска для сайта
Есть несколько типов данных, которые обычно можно чистить без последствий, если вы понимаете их назначение. Самые безопасные кандидаты — это ревизии, спам-комментарии, записи в корзине и временные данные с истекшим сроком жизни. Они не относятся к опубликованному контенту и не нужны для работы сайта.
Ревизии записей и страниц
WordPress сохраняет ревизии при каждом существенном изменении записи. Это удобно, но на длинной дистанции база раздувается очень заметно. Удалять ревизии можно, если вам не нужен полный архив всех промежуточных версий. На большинстве сайтов достаточно оставить несколько последних правок, а старые удалить.
Через SQL это делается так:
DELETE FROM wp_posts WHERE post_type = 'revision';После этого ревизии исчезнут из базы. Если вы хотите сначала оценить масштаб, можно посмотреть количество таких записей:
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';Если у вас большой сайт с редакцией контента, не удаляйте ревизии бездумно. Иногда они реально спасают при откате неудачного редактирования. В таком случае лучше сначала сократить их количество в настройках сайта на будущее, а старые удалить только после проверки.
Автосохранения и корзина
Автосохранения WordPress тоже хранятся в таблице wp_posts. Их обычно можно удалить, если сайт уже давно работает и черновики не нужны в старом объеме. Корзина записей и страниц тоже занимает место, особенно если ее не чистили месяцами.
Для удаления автосохранений используется тот же принцип, что и для ревизий, но с другим типом записи:
DELETE FROM wp_posts WHERE post_type = 'auto-draft';А для очистки корзины можно удалить записи со статусом trash:
DELETE FROM wp_posts WHERE post_status = 'trash';Здесь важно не перепутать статус и тип записи. Если сомневаетесь, сначала выполните запрос SELECT и посмотрите, что именно попадет под удаление.
Спам и удаленные комментарии
Комментарии тоже часто раздувают базу, особенно на старых сайтах с открытой формой комментирования. Спам и удаленные комментарии можно убрать без сожаления, если вы не используете их для модерации или аналитики.
DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';После удаления комментариев имеет смысл проверить, не остались ли связанные с ними метаданные в wp_commentmeta. Если комментарии удалялись массово, связанные записи иногда остаются в таблице метаданных и тоже занимают место.
Как убрать временные данные и мусор из wp_options
Одна из самых частых причин раздувания базы — таблица wp_options. В ней хранятся настройки сайта, кэшируемые значения и временные записи, которые WordPress и плагины создают на ограниченное время. Часть из них удаляется автоматически, но на практике просроченные transient-данные нередко остаются в базе надолго.
Если вы чистите wp_options вручную, не трогайте записи, назначение которых вам неясно. Ошибка здесь может сломать настройки темы, кэш, лицензии плагинов или поведение сайта. Безопаснее удалять только очевидные временные записи.
Просроченные transient-данные обычно имеют имена вида _transient_... и _transient_timeout_.... Сначала можно посмотреть, сколько их накопилось:
SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '\_transient\_%';Для удаления просроченных transient-данных используют запросы по парным ключам. Важно: удалять нужно и сам transient, и его timeout-запись, иначе в таблице останется мусор. На практике это зависит от того, как именно плагины хранят данные, поэтому перед массовым удалением лучше проверить структуру записей выборкой.
Если вы не уверены, какие transient безопасны, лучше ограничиться удалением только просроченных значений через SQL по времени жизни, а не чистить все подряд. Полная зачистка wp_options без понимания содержимого — плохая идея.
Оптимизация таблиц после очистки
После удаления большого количества строк база не всегда сразу становится компактнее на диске. Таблицы могут сохранить «пустое место» внутри файла данных. Чтобы вернуть это пространство и обновить статистику таблиц, используют оптимизацию.
Для большинства MySQL и MariaDB-серверов подойдет команда:
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_comments, wp_commentmeta, wp_options;Если таблиц больше, можно оптимизировать и остальные, но обычно именно эти пять растут быстрее всего. На некоторых хостингах команда OPTIMIZE TABLE может временно блокировать таблицу или выполняться дольше обычного. На небольшом сайте это обычно незаметно, а на крупном проекте лучше запускать операцию в низкую нагрузку.
Есть важная оговорка: эффект от оптимизации зависит от движка таблиц и версии MySQL/MariaDB. Для InnoDB поведение может отличаться от старых представлений о «сжатии» базы, но сама операция все равно полезна для обновления статистики и освобождения части пространства в ряде сценариев. Если хостинг ограничивает такие операции, лучше не пытаться обходить ограничения вручную.
Как сделать очистку через phpMyAdmin или консоль
Если у вас есть доступ только к панели хостинга, проще всего работать через phpMyAdmin. Там можно открыть нужную базу, перейти во вкладку SQL и выполнить запросы по одному. Это удобнее, чем редактировать файлы WordPress, потому что не требует изменения кода сайта.
Если есть доступ к SSH и установлен клиент MySQL, можно выполнять команды из консоли. Но этот способ стоит использовать только если вы уверенно ориентируетесь в базе и точно знаете имя базы, пользователя и пароль. Для обычной ручной чистки phpMyAdmin часто безопаснее.
Практический порядок действий такой:
- Сделайте резервную копию базы.
- Проверьте, сколько ревизий, спама и временных записей накопилось.
- Удалите только понятные типы мусора.
- Очистите корзину и просроченные временные данные.
- Выполните оптимизацию таблиц.
- Проверьте сайт после операции.
Если вы используете SQL-запросы, не запускайте их вслепую на продакшене. Сначала проверьте выборку через SELECT, потом уже удаление через DELETE. Это простое правило экономит много времени и нервов.
Что проверить после очистки
После ручной оптимизации не ограничивайтесь только сообщением «запрос выполнен успешно». Нужно убедиться, что сайт работает как раньше. Откройте главную страницу, несколько записей, страницу редактирования в админке, форму комментариев, если она используется, и проверьте сохранение новых материалов.
Если после чистки что-то сломалось, чаще всего причина в слишком агрессивном удалении данных из wp_options или в ошибочном SQL-запросе, который затронул не только мусор. Поэтому резервная копия здесь действительно обязательна. При наличии бэкапа восстановление обычно быстрее, чем попытка вручную искать, какая запись была удалена лишней.
Еще один полезный ориентир — размер базы до и после. В phpMyAdmin это видно по объему таблиц. Если вы удалили много ревизий и спама, а размер почти не изменился, значит основную нагрузку создают не они, а, например, тяжелые метаданные плагинов или огромная таблица wp_options. Тогда нужно смотреть уже на конкретные таблицы, а не чистить все подряд.
Когда ручная чистка подходит, а когда лучше не рисковать
Без плагинов имеет смысл чистить базу, если сайт небольшой или средний, вы понимаете структуру таблиц и можете сделать бэкап перед работой. Такой способ хорош, когда нужно убрать накопившийся мусор без установки дополнительных инструментов.
Если же сайт большой, с десятками плагинов, сложной структурой данных и несколькими редакторами, ручная чистка требует больше осторожности. В таких проектах особенно опасно удалять записи из wp_options, wp_postmeta и таблиц плагинов без понимания их связи с контентом. В этом случае лучше ограничиться безопасными действиями: ревизии, корзина, спам, просроченные transient-данные и оптимизация таблиц после проверки.
Если соблюдать этот порядок, база WordPress обычно быстро приходит в норму без установки дополнительных плагинов и без лишнего риска для сайта.