Если сайт на WordPress давно живёт и в нём активно редактируют записи, база данных почти всегда разрастается из-за ревизий и автосохранений. Это не ломает сайт само по себе, но увеличивает объём таблицы постов, усложняет резервное копирование и может замедлять обслуживание базы на слабом хостинге. Очистить это можно безопасно, если понимать, что именно удаляется и где не стоит действовать вслепую.
Сразу важный момент: удалять можно только старые ревизии и автосохранения, которые уже не нужны для восстановления контента. Текущие опубликованные записи, страницы и черновики трогать не нужно. Перед любой массовой очисткой сделайте резервную копию базы данных — это не формальность, а единственный нормальный способ откатиться, если вы удалите лишнее.
Что именно раздувает базу WordPress
WordPress хранит ревизии как отдельные записи в таблице wp_posts. Каждое сохранение редактором может создавать новую ревизию, а при работе в блоковом редакторе ещё и автосохранения. На сайтах с длинными текстами, частыми правками и несколькими авторами количество таких записей быстро становится большим.
Ревизии полезны: они позволяют откатить текст к предыдущей версии. Автосохранения тоже нужны, но только как временная страховка во время редактирования. Проблема начинается тогда, когда в базе накапливаются сотни или тысячи старых записей, которые уже не несут практической пользы.
Обычно это видно по одному из признаков:
- в phpMyAdmin или другом клиенте таблица
wp_postsзаметно больше остальных; - резервные копии базы стали дольше создаваться и занимают больше места;
- в админке при редактировании старых материалов WordPress показывает много ревизий;
- сайт работает нормально, но обслуживание базы стало заметно тяжелее.
Как безопасно очистить ревизии и автосохранения
Самый практичный путь — сначала удалить лишнее массово, а потом при необходимости ограничить их дальнейшее накопление. Для очистки есть два рабочих сценария: через плагин и через SQL-запросы. Если вам нужен разовый и понятный способ без ручной работы с базой, удобнее плагин. Если вы уверенно работаете с phpMyAdmin или консолью и хотите точечный контроль, можно использовать SQL.
Вариант 1. Очистка через плагин
Для большинства владельцев сайтов это самый безопасный вариант. Подходящий инструмент должен уметь находить ревизии, автосохранения и удалять их без затрагивания обычных записей. Если у вас уже используется Clearfy Pro, в нём есть функции для чистки базы и удаления лишних данных WordPress; это удобно, когда нужно решить задачу без ручных запросов к базе.
Общий порядок действий одинаковый для большинства подобных плагинов:
- сделайте резервную копию базы данных;
- откройте раздел очистки базы в админке WordPress;
- выберите удаление ревизий и, если нужно, автосохранений;
- запустите очистку;
- проверьте, что количество записей уменьшилось.
Плюс этого способа в том, что плагин обычно сам учитывает особенности структуры WordPress и не требует писать SQL вручную. Минус — вы зависите от интерфейса и логики конкретного плагина, поэтому перед запуском всё равно нужно смотреть, какие именно типы данных будут удалены.
Вариант 2. Удаление через SQL
Если вы хотите очистить базу без плагинов, можно удалить ревизии и автосохранения напрямую из таблицы wp_posts. Этот способ подходит только если вы понимаете, что делаете, и уже сохранили резервную копию базы. Ошибка в запросе может удалить не то, что нужно.
Сначала проверьте, сколько таких записей накопилось. В phpMyAdmin или другом SQL-клиенте выполните запрос:
SELECT post_type, COUNT(*) AS cnt<br>FROM wp_posts<br>WHERE post_type IN ('revision', 'autosave')<br>GROUP BY post_type;Если в вашей базе префикс таблиц не wp_, замените его на свой. Результат покажет, сколько ревизий и автосохранений есть сейчас.
Чтобы удалить ревизии, используйте такой запрос:
DELETE FROM wp_posts<br>WHERE post_type = 'revision';Автосохранения в WordPress обычно не хранятся как отдельный post_type = 'autosave' в стандартной установке. Чаще автосохранение привязано к записи и проявляется как служебная версия редактирования. Поэтому на практике основная масса мусора — это именно ревизии. Если вы используете нестандартные плагины или кастомную логику, сначала проверьте структуру данных, а не удаляйте записи вслепую.
После удаления ревизий полезно очистить связанные метаданные, которые могли остаться в базе. Для этого обычно используют запрос к wp_postmeta только если вы уверены, что удалённые записи больше не нужны и у вас есть бэкап. В обычной ситуации достаточно удалить сами ревизии, а затем при необходимости дать базе оптимизироваться.
Как не потерять нужные версии контента
Главная ошибка при очистке — удалять всё подряд, не проверив, есть ли среди ревизий действительно полезные версии. Если над статьями работают несколько авторов или клиент часто вносит правки, ревизии могут быть полезны для отката. В таком случае лучше не удалять всё без разбора, а оставить хотя бы последние версии для важных страниц.
Практически это выглядит так:
- для старых публикаций, которые давно не редактировались, ревизии обычно можно удалить без риска;
- для свежих материалов и посадочных страниц лучше сначала открыть запись и убедиться, что текущая версия сохранена;
- если на сайте есть важные страницы с историей правок, сначала экспортируйте или сохраните их содержимое отдельно.
Если вы работаете через SQL, не забывайте, что удаление необратимо без резервной копии. Если через плагин — проверьте, есть ли у него возможность предварительного просмотра или хотя бы список типов данных, которые будут очищены.
Как ограничить накопление ревизий в будущем
После очистки имеет смысл уменьшить скорость повторного роста базы. Полностью отключать ревизии обычно не стоит: они реально спасают при ошибках редактирования. Но можно ограничить их количество. Для этого в wp-config.php добавляют константу WP_POST_REVISIONS.
Например, чтобы оставить не больше трёх ревизий на запись, добавьте в wp-config.php строку выше комментария /* That's all, stop editing! Happy publishing. */:
define('WP_POST_REVISIONS', 3);Если поставить false, WordPress перестанет сохранять ревизии, но это уже жёсткое решение. Для большинства сайтов разумнее ограничить количество, а не отключать механизм полностью. Это особенно важно для редакционных проектов, где ошибки в тексте случаются регулярно.
Есть ещё один полезный параметр — интервал автосохранения. По умолчанию WordPress сохраняет черновик достаточно часто, и это нормально для длинной работы над текстом. Менять его стоит только если вы понимаете последствия. Слишком редкое автосохранение повышает риск потерять внесённые правки при сбое браузера или соединения.
Как проверить, что очистка сработала
После удаления не ограничивайтесь ощущением, что «что-то стало легче». Проверьте результат по факту. Самый простой способ — снова выполнить запрос на подсчёт ревизий и сравнить число до и после очистки. Если вы использовали плагин, посмотрите отчёт о выполненной операции или повторно откройте раздел очистки базы.
Полезно также проверить размер базы на уровне хостинга или в phpMyAdmin. Если таблица wp_posts была сильно перегружена ревизиями, её размер должен заметно уменьшиться. При этом не ждите мгновенного ускорения всего сайта: очистка базы помогает в обслуживании и снижает лишний объём данных, но не заменяет оптимизацию темы, плагинов и запросов к базе.
Если после очистки сайт начал вести себя странно, сначала проверьте, не удалили ли вы что-то лишнее. В такой ситуации восстановление из резервной копии обычно быстрее и надёжнее, чем попытка вручную собирать удалённые данные обратно.
Когда лучше не делать очистку вручную
Если база большая, сайт многосайтовый, а вы не уверены в структуре таблиц и префиксах, не стоит начинать с SQL-запросов. То же самое относится к ситуациям, когда на сайте есть нестандартные плагины для редакторского процесса, кастомные типы записей или сложная схема хранения контента. В таких случаях безопаснее использовать инструмент, который работает через интерфейс WordPress и уже учитывает типовые ограничения.
Ручная очистка оправдана, когда вы точно знаете, что в базе накопились именно ревизии, у вас есть свежий бэкап и вы готовы проверить результат после операции. Во всех остальных случаях лучше выбрать более осторожный путь: сначала резервная копия, потом очистка через проверенный инструмент, затем контрольный просмотр базы.
Если задача стоит не только в разовой очистке, но и в регулярном обслуживании сайта, удобно совмещать удаление ревизий с общей чисткой базы. Для этого подойдут инструменты, которые умеют удалять лишние данные WordPress без ручной работы с SQL и позволяют не трогать нужные записи.