WordPress накапливает мусор в базе данных: черновики ревизий постов, transient-кэш, логи плагинов, orphaned meta. Объём базы может вырасти с 10 MB до 1 GB без видимой причины — и это тормозит весь сайт, потому что каждый запрос вида WP_Query сканирует раздутые таблицы wp_posts и wp_options.

Что засоряет базу данных WordPress

Тип мусора	Таблица	Типичный объём
Ревизии постов	wp_posts	10–500 МБ
Transients (кэш плагинов)	wp_options	50–200 МБ
Autoload options	wp_options	1–50 МБ
Логи плагинов	Разные	1–100 МБ
Orphaned postmeta	wp_postmeta	5–50 МБ

Очистка через WP-CLI

# Удалить все ревизии постов
wp post delete $(wp post list --post_type=revision --format=ids) --force

# Удалить истёкшие transients
wp transient delete --expired

# Удалить все transients
wp transient delete --all

# Оптимизировать все таблицы
wp db optimize

Ограничить ревизии в wp-config.php

// Максимум 3 ревизии на пост
define('WP_POST_REVISIONS', 3);

// Полностью отключить ревизии
define('WP_POST_REVISIONS', false);

// Автосохранение каждые 120 секунд (вместо 60)
define('AUTOSAVE_INTERVAL', 120);

Рекомендуем хранить 3–5 ревизий — это даёт возможность отката без лишней нагрузки на диск и на резервное копирование.

Проблемные autoload-опции

Каждый запрос страницы WordPress подгружает в память все опции с autoload='yes' одним запросом. Если суммарный размер autoload превышает 1 МБ, каждый хит по сайту тратит время на десериализацию мусора, который никто не читает.

# Найти большие autoload-опции
wp db query "SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload='yes'
ORDER BY size DESC
LIMIT 20;"

# Суммарный вес autoload — цифра, на которую стоит смотреть
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';"

Не удаляйте опции без понимания — некоторые критичны для работы плагинов. Сначала сделайте бэкап БД: wp db export before-cleanup.sql.

Разбор типичных ошибок оптимизации

Error establishing a database connection после массового DELETE по ревизиям — таблица wp_posts заблокирована долгой транзакцией на MyISAM; переключите движок на InnoDB, который блокирует только затронутые строки.
WSOD (белый экран) сразу после удаления transients — плагин ожидал опцию, которую чистящий скрипт удалил вместе с мусором; восстановите из бэкапа и удаляйте transients точечно по префиксу плагина.
Table './wp/wp_options' is marked as crashed — MyISAM-таблица повреждена во время параллельной записи при чистке; чинится командой wp db repair или REPAIR TABLE wp_options;.
Сайт не ускорился после wp db optimize — команда дефрагментирует таблицы, но не трогает autoload; если тормозит именно первая загрузка опций, ищите причину через запрос суммы autoload выше.
Lock wait timeout exceeded; try restarting transaction — плагин чистки и cron-задание другого плагина одновременно пишут в одну таблицу; запускайте массовые операции вручную вне окна активного cron, а не через веб-крон при живом трафике.

Плагины для оптимизации БД

WP-Optimize — автоматическая очистка по расписанию, включая удаление спам-комментариев и заброшенных таблиц старых плагинов.
Advanced Database Cleaner — подробная статистика мусора с разбивкой по таблицам и возможностью экспорта отчёта.
Sweep — простой и безопасный клинер без агрессивных настроек по умолчанию.

Сравнение способов очистки

Способ	Скорость	Риск	Когда применять
WP-CLI на VDS	Высокая	Низкий при бэкапе	Есть SSH-доступ и cron
Плагин в админке	Средняя	Средний	Нет доступа к консоли
Ручной SQL через phpMyAdmin	Высокая	Высокий	Точечная правка одной опции

Когда оптимизация БД не поможет

Иногда база выглядит здоровой, а сайт всё равно медленный — тогда дело не в мусоре:

Тормозят внешние запросы (шрифты, виджеты соцсетей, сторонние API) — их не видно в запросах к MySQL, ищите через вкладку Network в браузере.
Не хватает памяти PHP или CPU у самого сервера — wp db optimize не увеличит memory_limit и не ускорит рендеринг шаблона.
Нет кэша страниц (page cache) — без него WordPress выполняет полный набор запросов на каждый визит, даже к идеально оптимизированной базе; общий разбор всех факторов скорости — в статье про ускорение WordPress.

Как проверить результат

# Размер базы до и после — сравниваем эти два числа
wp db size --size_format=mb

# Время выполнения главной страницы: замеряем до и после чистки
curl -o /dev/null -s -w 'time_total: %{time_total}s\n' https://example.com/

# Проверяем, что сайт открывается без ошибок PHP
wp eval 'echo "OK: " . get_bloginfo("name");'

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