Раздутая база данных WordPress увеличивает TTFB (Time to First Byte) на 200-500 мс, что напрямую режет конверсию и позиции в выдаче. Оптимизация SQL-слоя — это не просто удаление спама, а работа с индексами и структурой таблиц, которая снижает нагрузку на CPU сервера на 30-40%.
Мусор в wp_options и autoload
Самая критическая точка — таблица wp_options. Плагины часто оставляют там «хвосты» после удаления, которые загружаются при каждом хите сайта через параметр autoload = 'yes'. Если размер autoload-данных превышает 1 МБ, время генерации страницы растет линейно.
Кейс: на проекте с 50+ установленными за время жизни плагинами объем autoload составлял 4.2 МБ. Очистка неиспользуемых опций и перевод тяжелых настроек в autoload = 'no' сократила время отклика сервера с 800 мс до 350 мс.
Экспертный вывод: всегда проверяйте запрос SELECT sum(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; — если цифра выше 1 МБ, ваш сайт тормозит из-за мусора.
Оптимизация ревизий и метаданных
По умолчанию WordPress хранит каждую правку поста. На сайтах с активным контент-маркетингом (10+ статей в неделю) таблица wp_posts и wp_postmeta разрастаются до гигабайтов за год. Это замедляет SQL-запросы на поиск и фильтрацию, увеличивая время выполнения тяжелых JOIN-ов на 15-25%.
- Лимит ревизий: установите 'WP_POST_REVISIONS' в 3-5 или вовсе 0 в wp-config.php.
- Очистка orphan-метаданных: удаление записей в wp_postmeta, которые не привязаны к существующим постам.
Экспертный вывод: хранить 50 версий одного текста бессмысленно. Ограничение ревизий до 5 штук экономит до 60% объема таблицы wp_posts на крупных медиа-ресурсах.
Индексация и структура URL
Стандартные индексы MySQL в WordPress оптимизированы под простые блоги, но пасуют при сложных таксономиях. Ошибки в структуре URL и таксономии WordPress приводят к созданию избыточных записей в таблице wp_term_relationships, что замедляет генерацию категорий и тегов.
Пример: при переходе на кастомные таксономии без очистки старых связей размер таблицы отношений может вырасти в 3-4 раза, создавая лишнюю нагрузку на диск (I/O). Оптимизация индексов (добавление составных индексов на часто запрашиваемые поля) ускоряет сложные выборки в 2-5 раз.
Экспертный вывод: если у вас более 10 000 товаров или статей, стандартных индексов недостаточно — требуется ручной аудит медленных запросов через Slow Query Log.
Транзакционный лог и пересоздание таблиц
Со временем таблицы MySQL фрагментируются, особенно после массовых удалений (например, очистки спам-комментариев). Это приводит к «дырам» в данных, из-за чего сервер читает больше блоков с диска, чем реально нужно. Команда OPTIMIZE TABLE позволяет пересобрать индекс и сжать физический размер файла базы данных.
Практика показывает, что после OPTIMIZE на БД объемом 2 ГБ реальный размер файла на диске может сократиться до 1.6 ГБ (экономия до 20%), что ускоряет бэкапы и миграции.
Экспертный вывод: выполняйте оптимизацию таблиц раз в квартал или после каждого массового удаления данных, чтобы избежать деградации производительности дисковой подсистемы.
Вывод
Начните с жесткого лимита ревизий в wp-config.php и чистки autoload в wp_options — это дает 80% результата при минимальных затратах. Избегайте «автоматических оптимизаторов» в виде тяжелых плагинов, которые сами нагружают БД; используйте WP-CLI или прямые SQL-запросы. Мой выбор: ручная чистка раз в месяц + настройка MariaDB с оптимизированным buffer pool size под объем вашего RAM.