Раздутая база данных WordPress увеличивает время ответа сервера (TTFB) на 300–800 мс, что напрямую режет конверсию и позиции в выдаче. Оптимизация SQL-запросов и очистка таблиц позволяют сократить объем БД в 2–5 раз, возвращая сайту скорость работы «свежего» движка.
Мусор в wp_options и автозагрузка
Таблица wp_options — главный тормоз сайта. Проблема в поле autoload: если сумма всех строк с autoload='yes' превышает 1 МБ, WordPress начинает тормозить на каждом хите. В реальных кейсах после удаления старых настроек удаленных плагинов размер автозагрузки падает с 5–10 МБ до 400 КБ, что сокращает время генерации страницы на 150–200 мс.
Используйте запрос SQL для поиска тяжелых опций: SELECT option_name, length(option_value) AS size FROM wp_options WHERE autoload = 'yes' ORDER BY size DESC LIMIT 20;
Экспертный вывод: Очищайте autoload вручную. Плагины-оптимизаторы часто пропускают «хвосты» от старых тем, которые продолжают грузиться в память при каждом посещении.
Ревизии и транзиенты: скрытый вес
По умолчанию WordPress хранит каждую правку поста. На сайтах с 1000+ статей и активным редактированием таблица wp_posts разрастается до гигабайтов из-за ревизий. Очистка ревизий и удаление истекших транзиентов (временных записей) сокращает размер БД в среднем на 30–60% без потери контента.
Кейс: Интернет-магазин с 5000 товаров имел БД объемом 4.2 ГБ. После удаления ревизий и очистки таблицы wp_options от старых сессий размер упал до 800 МБ, а скорость выполнения тяжелых SQL-запросов выросла в 3 раза.
Экспертный вывод: Ограничьте количество ревизий до 3–5 через wp-config.php (define('WP_POST_REVISIONS', 5);). Хранить 50 версий одной статьи — бессмысленный расход ресурсов диска и памяти.
Индексация и оптимизация структуры таблиц
Стандартные индексы WordPress не всегда оптимальны для сложных запросов (например, при фильтрации по мета-полям). Добавление кастомных индексов в таблицу wp_postmeta для часто запрашиваемых ключей сокращает время выполнения Slow Queries с 2–3 секунд до 0.05 секунды.
Важный нюанс: использование типа данных InnoDB вместо MyISAM обязательно. InnoDB поддерживает транзакции и блокировку на уровне строк, а не всей таблицы, что критично при высокой посещаемости (от 5000 чел/сутки). Переход на InnoDB снижает риск «зависания» сайта при записи данных.
Экспертный вывод: Если ваш сайт перерос уровень блога, проверьте индексы. Без них даже самый мощный сервер будет простаивать, ожидая ответа от SQL-запроса.
Влияние темы и плагинов на SQL
Некоторые темы создают собственные таблицы в БД или перегружают стандартные сотнями записей в postmeta. При выборе софта важно смотреть на количество SQL-запросов на одну страницу. Нормой считается до 80–100 запросов; если их 200+, сайт будет тормозить даже на NVMe-дисках.
Пример: Смена тяжелого конструктора страниц на решение, где соблюдены критерии выбора SEO-дружественной темы для WordPress, снижает количество запросов к БД на 40–70%, что дает прирост к PageSpeed на 10–15 пунктов.
Экспертный вывод: Оптимизация БД бесполезна, если тема генерирует избыточные запросы. Сначала сокращайте количество вызовов, затем оптимизируйте сами таблицы.
Вывод
Оптимизация базы данных WordPress SQL — это не разовый клик по кнопке «Очистить», а гигиена: ограничение ревизий в config, ручной анализ autoload в wp_options и переход на InnoDB. Начинайте с анализа размера автозагрузки (норма до 1 МБ) и удаления мусора от старых плагинов. Избегайте автоматических «клинеров», которые удаляют данные без бэкапа; используйте SQL-запросы для точечного удаления. Результатом станет снижение TTFB на 200–500 мс, что является фундаментом для дальнейшего SEO-продвижения.