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

Що засмічує базу даних WordPress

Тип сміття	Таблиця	Типовий обсяг
Ревізії постів	wp_posts	10–500 МБ
Transients (кеш плагінів)	wp_options	50–200 МБ
Autoload-опції	wp_options	1–50 МБ
Логи плагінів	Різні	1–100 МБ
Осиротілі 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 тижні, інакше сміття накопичиться знову.