Раздутая база данных MySQL замедляет TTFB (Time to First Byte) на 200-500 мс, что напрямую режет конверсию и позиции в выдаче. Оптимизация БД — это не просто удаление старых ревизий, а тонкая настройка индексов и очистка таблицы wp_options, которая в запущенных проектах может разрастаться до 500 МБ при норме в 2-5 МБ.
Очистка мусора в таблицах wp_posts и wp_postmeta
Основной вес БД набирают ревизии постов и автосохранения. На сайтах с активным контент-маркетингом (от 500 статей) количество записей в wp_posts может быть в 5-10 раз больше реальных страниц. Удаление ревизий старше 3-х месяцев сокращает размер таблицы на 30-60%, что ускоряет выполнение тяжелых SELECT-запросов.
Кейс: очистка БД интернет-магазина с 2000 товаров и 15 ревизиями на каждый товар позволила сократить размер БД с 1.2 ГБ до 450 МБ. Это снизило нагрузку на CPU сервера с 40% до 15% при пиковых посещениях. Экспертный вывод: ограничьте число ревизий до 3-5 через wp-config.php, чтобы база не раздувалась повторно.
Оптимизация таблицы wp_options и автозагрузки
Критическая ошибка многих администраторов — игнорирование флага autoload в таблице wp_options. Все записи с autoload = 'yes' подгружаются в память при каждом запросе к любой странице сайта. Если этот объем превышает 1 МБ, сайт начинает «тормозить» даже на мощном VPS.
Практика показывает, что плагины-однодневки оставляют после удаления «хвосты» объемом до 100 КБ на каждый плагин. Рекомендую вручную проверять топ-20 самых тяжелых строк в wp_options. Экспертный вывод: любой параметр с autoload = 'yes', который не используется на каждой странице, должен быть переведен в 'no' или удален.
Индексация и работа с типами данных
Стандартные индексы WordPress оптимизированы под общие задачи, но при росте базы до 100+ тысяч строк стандартный поиск по meta_value начинает работать крайне медленно. Внедрение дополнительных индексов на часто запрашиваемые поля сокращает время отклика БД с 1.5 сек до 0.1 сек.
Важный нюанс: использование InnoDB вместо старого MyISAM обязательно. InnoDB поддерживает построчное блокирование, что в 3-4 раза повышает производительность при одновременной записи и чтении данных. Экспертный вывод: если ваш сайт перерос уровень визитки, переходите на MariaDB 10.6+ с настроенным innodb_buffer_pool_size (минимум 50-70% от доступной RAM сервера).
Борьба с транзиентными записями и кэшем
Транзиенты (временные опции) в WordPress часто не удаляются автоматически из-за сбоев в cron. В результате таблица wp_options забивается сотнями записей с истекшим сроком годности. При интенсивном использовании API (например, WooCommerce или внешних сервисов доставки) объем транзиентов может достигать 20-30% от общего веса БД.
Сравнение: ручная очистка через SQL-запрос раз в месяц против использования Redis/Memcached. Внедрение Redis переносит кэш из MySQL в оперативную память, что снижает количество запросов к БД на 40-60%. Экспертный вывод: для высоконагруженных проектов полностью откажитесь от хранения транзиентов в MySQL в пользу объектного кэширования.
Вывод
Оптимизацию БД нужно начинать с жесткого лимита ревизий и чистки autoload-опций — это дает 80% результата при нулевых затратах. Избегайте автоматических «плагинов-чистильщиков», которые работают по таймеру, так как они создают лишнюю нагрузку на диск; делайте глубокую очистку вручную раз в квартал. Мой выбор для серьезных проектов: связка MariaDB + Redis + ручной аудит таблицы wp_options.