Как очистить таблицы автосохранений и ревизий в WordPress

Если сайт давно живёт и посты редактируются регулярно, база WordPress часто разрастается не из-за медиафайлов, а из-за автосохранений и ревизий. Это не ошибка: WordPress специально хранит версии записей, чтобы можно было откатиться к предыдущему состоянию. Проблема начинается тогда, когда ревизий становится слишком много, а старые автосохранения уже не нужны. В таком случае база занимает больше места, резервные копии растут, а работа с таблицей wp_posts становится тяжелее.

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

Что именно удаляется при очистке

В WordPress ревизии и автосохранения хранятся в таблице wp_posts как отдельные записи с разными типами постов.

• revision — ревизии записей и страниц;
• auto-draft — черновики, которые WordPress создаёт автоматически;
• автосохранения редактора — отдельные служебные записи, которые помогают не потерять текст при сбое браузера или соединения.

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

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

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

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

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

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

Если сайт на общем хостинге, обычно проще всего использовать встроенный инструмент резервного копирования панели управления или экспорт базы через phpMyAdmin. На VPS и выделенных серверах удобнее делать дамп средствами MySQL/MariaDB, но это уже зависит от доступа к серверу.

Самый безопасный способ: плагин для очистки базы

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

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

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

Удаление ревизий и автосохранений через SQL

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

В WordPress префикс таблиц не всегда wp_. Если у вас другой префикс, замените его в запросе на свой. Перед удалением можно посмотреть, сколько записей накопилось:

SELECT post_type, COUNT(*) AS total
FROM wp_posts
WHERE post_type IN ('revision', 'auto-draft')
GROUP BY post_type;

Если нужно удалить все ревизии, используйте такой запрос:

DELETE FROM wp_posts
WHERE post_type = 'revision';

Чтобы удалить автосохранения-черновики, обычно очищают записи типа auto-draft:

DELETE FROM wp_posts
WHERE post_type = 'auto-draft';

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

Если вы работаете через phpMyAdmin, сначала выполните SELECT-запрос и убедитесь, что он показывает именно те записи, которые вы хотите удалить. Только после этого запускайте DELETE.

Как ограничить количество ревизий в будущем

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

Добавьте строку выше комментария /* That's all, stop editing! Happy publishing. */:

define('WP_POST_REVISIONS', 5);

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

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

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

После очистки не ориентируйтесь только на визуальное ощущение. Проверьте результат по числу записей и по размеру базы.

Что можно посмотреть:

• количество записей с типом revision и auto-draft в wp_posts;
• размер таблицы wp_posts и базы в целом в phpMyAdmin или панели хостинга;
• отклик админки при редактировании больших записей.

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

Когда лучше не чистить вручную

Ручная очистка не лучший вариант, если сайт активно редактируется несколькими авторами, а вы не уверены в структуре базы или не имеете доступа к нормальному бэкапу. В такой ситуации безопаснее использовать инструмент, который показывает список удаляемых данных и не требует писать SQL руками.

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

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

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