Раздутая база данных WordPress увеличивает TTFB (Time to First Byte) на 200-500 мс, что напрямую режет конверсию и позиции в выдаче. Оптимизация SQL-слоя — это не про удаление спам-комментариев, а про работу с индексами и борью с мусором в wp_options и wp_postmeta.
Анатомия мусора в таблицах wp_options и postmeta
Основной тормоз WordPress — autoloaded options. Когда значение 'all_options' в таблице wp_options превышает 1 МБ, MySQL начинает заметно тормозить при каждом запросе. Типичный кейс: после удаления 5-10 старых плагинов в базе остаются десятки записей с autoload = 'yes', которые загружаются при каждом хите, даже если плагин не активен.
В таблице wp_postmeta проблема в избыточности: один товар в WooCommerce может генерировать до 40-60 мета-полей. Очистка неиспользуемых мета-ключей (orphaned metadata) сокращает размер таблицы на 15-30%, что ускоряет сложные SQL-запросы на фильтрацию товаров на 10-15%.
Экспертный вывод: Первым делом чистите autoload в wp_options. Если сумма всех autoload-данных > 800 КБ — ваш сервер тратит ресурсы впустую.
Ревизии и транзиенты: скрытые пожиратели места
По умолчанию WordPress хранит каждую правку статьи. На контентных проектах с 1000+ страниц и частым обновлением база может вырасти с 200 МБ до 2 ГБ за полгода только за счет ревизий. Это раздувает индексы и замедляет поиск по базе. Отключение ревизий через wp-config.php (define('WP_POST_REVISIONS', 3)) ограничивает их число, предотвращая экспоненциальный рост.
Транзиенты (временные опции) часто «зависают» в базе, если срок их жизни (expiration) не сработал корректно. В высоконагруженных магазинах таблица wp_options может быть забита тысячами просроченных транзиентов, что создает лишнюю нагрузку на I/O диска.
Экспертный вывод: Ограничьте ревизии до 3-5 копий. Хранить 50 версий одного текста в SQL-базе — технический абсурд, который убивает производительность.
Оптимизация индексов и переход на InnoDB
Использование устаревшего движка MyISAM приводит к блокировке всей таблицы при любой операции записи, что вызывает «зависание» сайта при пиковых нагрузках. Переход на InnoDB позволяет блокировать только конкретные строки, что увеличивает пропускную способность БД в 2-3 раза на многопользовательских сайтах.
Критическая ошибка — отсутствие индексов в кастомных таблицах или при использовании сложных WP_Query. Добавление одного составного индекса на часто запрашиваемые поля может сократить время выполнения тяжелого запроса с 1.2 сек до 0.04 сек. Это база для тех, кто делает серьезную SEO оптимизация сайтов на WordPress.
Экспертный вывод: Только InnoDB. Если у вас MyISAM — конвертируйте немедленно, иначе любой всплеск трафика приведет к ошибке 504 Gateway Timeout.
Сравнение инструментов: плагины против SQL-запросов
Плагины вроде WP-Optimize или Advanced Database Cleaner удобны, но работают медленно и иногда пропускают глубокие системные остатки. Ручная очистка через phpMyAdmin или консоль (например, запрос DELETE FROM wp_options WHERE autoload = 'yes' AND option_name NOT IN (...)) работает в 10 раз быстрее и чище.
Сравнение: плагин тратит 30-60 секунд на сканирование и может вызвать тайм-аут сервера на больших БД (> 500 МБ), в то время как прямой SQL-запрос выполняется за 0.1-0.5 сек. При этом риск ошибки при ручном удалении выше, что требует обязательного бэкапа.
Экспертный вывод: Для малых сайтов до 100 МБ подойдут плагины. Для крупных проектов — только прямой SQL и регулярные задания в cron на очистку транзиентов.
Вывод
Оптимизация БД — это фундамент скорости. Начинайте с анализа размера autoload в wp_options, затем переходите к ограничению ревизий и конвертации всех таблиц в InnoDB. Избегайте автоматических «клинеров» на живых базах объемом более 1 ГБ — только ручные SQL-запросы после полного дампа. Идеальный результат: размер базы минимален, TTFB < 200 мс, а индексы настроены под ваши самые тяжелые запросы.