Раздутая база данных WordPress увеличивает время отклика сервера (TTFB) на 300-800 мс, что напрямую режет конверсию и позиции в выдаче. Оптимизация SQL-слоя — это не про «очистку кэша», а про сокращение объема таблиц с гигабайтов до мегабайтов для ускорения выполнения тяжелых JOIN-запросов.
Мусор в wp_options и автозагрузка
Таблица wp_options — главное «бутылочное горлышко». Главная проблема — поле autoload. Если объем данных с флагом autoload превышает 1 МБ, WordPress подгружает этот массив при каждом запросе, перегружая RAM сервера. Часто плагины-однодневки оставляют там десятки записей, которые не используются годами.
Кейс: на проекте с 50 000 визитов в сутки очистка неактивных опций сократила размер таблицы с 120 МБ до 15 МБ, что снизило нагрузку на CPU сервера на 12%. Инструментами очистки выступают SQL-запросы на поиск сирот (orphaned options) и анализ объема автозагрузки.
Вывод эксперта: Всегда проверяйте размер автозагрузки через запрос SUM(LENGTH(option_value)). Если цифра выше 500 КБ — ваш сайт работает медленнее, чем мог бы.
Ревизии и метаданные: скрытый вес
По умолчанию WordPress хранит каждую правку поста. На сайтах с активным контент-маркетингом (более 500 статей) таблица wp_posts раздувается в 3-5 раз из-за ревизий. Еще опаснее wp_postmeta, где скапливаются «ошметки» от удаленных плагино-конструкторов (Elementor, Divi), создавая тысячи бесполезных строк.
Пример: удаление ревизий и очистка метаданных на сайте с 2000 страниц сократило размер БД с 1.4 ГБ до 300 МБ. Это ускорило выполнение административных запросов в панели управления в 2 раза.
Вывод эксперта: Ограничьте количество ревизий до 3-5 через wp-config.php (define('WP_POST_REVISIONS', 3)). Хранить 50 версий одной статьи — архитектурная ошибка.
Трансгрессия индексов и InnoDB
Многие до сих пор используют MyISAM, хотя InnoDB с поддержкой row-level locking (блокировка на уровне строки) критична для высоконагруженных проектов. Отсутствие правильных индексов в кастомных таблицах плагинов приводит к Full Table Scan, когда MySQL перебирает миллионы строк вместо точечного поиска.
Практика: замена MyISAM на InnoDB и добавление индекса по колонке мета_ключа в тяжелых таблицах сокращает время выполнения сложных запросов с 2.4 сек до 0.05 сек. Это база для качественной SEO оптимизации сайтов на WordPress.
Вывод эксперта: Переходите на InnoDB и используйте инструмент EXPLAIN перед тяжелыми SQL-запросами, чтобы видеть, где база «спотыкается» из-за отсутствия индекса.
Оптимизация логов и транзиентных данных
Таблицы логов (например, от WooCommerce или плагинов безопасности) могут расти экспоненциально, достигая 2-3 ГБ за квартал. Транзиенты (временные опции) в wp_options часто не удаляются автоматически из-за сбоев в кроне, создавая избыточный шум в БД.
Сценарий: очистка таблицы wp_woocommerce_order_items и удаление просроченных транзиентов раз в месяц высвобождает до 20% дискового пространства БД, что ускоряет создание бэкапов с 15 минут до 3 минут.
Вывод эксперта: Настройте автоматическую очистку логов через SQL-события (Events) или специализированные плагины, но только после ручного анализа структуры таблиц.
Вывод
Оптимизация БД — это гигиена, без которой любой кеширующий плагин будет лишь маскировать проблему. Начните с жесткого лимита ревизий и очистки wp_options от мусора автозагрузки. Избегайте «универсальных» плагинов-чистилок, которые удаляют данные без бэкапа; используйте точечные SQL-запросы. Мой выбор: ручная оптимизация индексов + переход на InnoDB и строгий контроль за объемом автозагрузки (до 500 КБ).