Индексация базы данных WooCommerce: какие ключи добавить для ускорения запросов

Клиент жалуется: «Магазин тормозит, фильтры виснут по 5–7 секунд, заказы обрабатываются медленно». Вы смотрите на сервер — ресурсов хватает. Кэш настроен. CDN подключён. А проблема никуда не делась. Знакомая ситуация?

В 90% случаев, когда WooCommerce-магазин «тупит» при нормальном хостинге, причина кроется не в PHP и не в плагинах — в неоптимизированной базе данных. Таблицы растут, запросы становятся тяжелее, а MySQL вынужден сканировать сотни тысяч строк, чтобы вернуть десяток. Исправляется это добавлением правильных индексов — ключей, которые указывают базе данных, где именно искать.

В этой статье разберём, какие индексы реально нужны WooCommerce-магазину, как их добавить и что это даёт на практике.

Почему WooCommerce работает медленно на больших объёмах

WooCommerce построен на WordPress, а WordPress — на так называемой EAV-архитектуре (Entity-Attribute-Value). Все данные о товарах хранятся не в одном удобном месте, а размазаны по таблице wp_postmeta. Название товара — в одном ряду. Цена — в другом. Артикул — в третьем. Для одного товара может быть 20–40 строк в postmeta.

Теперь представьте: у вас 5 000 товаров. Это уже 100 000–200 000 строк в postmeta. Добавьте сюда заказы, их мета-данные, транзакции — и вы получаете таблицу на несколько миллионов строк.

Когда WooCommerce строит фильтр по цене или формирует список заказов в админке, он делает JOIN между таблицами. Без индексов MySQL перебирает каждую строку вручную — это называется full table scan. На 100 строках незаметно. На миллионах — катастрофа.

Как проверить, какие запросы тормозят

Прежде чем хрустеть индексами, нужно понять, что именно болит. Есть несколько способов диагностики:

• Плагин Query Monitor — показывает все SQL-запросы на странице с временем выполнения. Страница с 50+ запросами, каждый по 0.5 секунды, — это уже красный флаг.
• MySQL Slow Query Log — включается на сервере, логирует все запросы дольше заданного порога (обычно 1–2 секунды).
• EXPLAIN — команда, которая показывает план выполнения запроса. Если в колонке type видите ALL — значит, сканируется вся таблица. Значит, индекс нужен.

Пример использования EXPLAIN:

EXPLAIN SELECT * FROM wp_postmeta
WHERE meta_key = '_price' AND meta_value > 1000;

Если результат показывает rows: 480000 и type: ALL — вот ваша проблема. После добавления индекса тот же запрос отработает в десятки раз быстрее.

Какие таблицы WooCommerce нужно индексировать

Разберём основные таблицы, которые страдают больше всего. Я приведу готовые SQL-запросы — можно выполнить через phpMyAdmin или WP-CLI.

wp_postmeta — мета-данные товаров и заказов

Это главная боль WooCommerce. По умолчанию в таблице есть только индекс на post_id и meta_key. Но часто нужны выборки по конкретным ключам — цена, наличие, артикул. Для этого добавляем составной индекс:

ALTER TABLE wp_postmeta ADD INDEX idx_meta_key_value (meta_key(50), meta_value(50));

Конкретный размер префикса (50) подбирайте под свои данные. Если значения короткие — можно уменьшить.

Популярные запросы, которые ускоряются:

• Фильтр по цене (_price)
• Поиск по артикулу (_sku)
• Фильтр по наличию (_stock_status)
• Сортировка по дате создания (_wc_average_rating)

wp_options — таблица настроек и транзиентов

WooCommerce хранит в wp_options кэшированные данные: транзиенты, настройки магазина, сессии. Каждый заголовок страницы инициирует запрос к этой таблице. Если транзиентов накопилось несколько тысяч — без индекса всё тормозит.

ALTER TABLE wp_options ADD INDEX idx_option_name (option_name(50));

Кстати, раз в несколько месяцев полезно чистить устаревшие транзиенты. У меня был случай: таблица wp_options весила 800 МБ, из которых 700 — мёртвые транзиенты. После очистки и добавления индекса админка ожила.

wp_wc_order_stats — статистика заказов

Эта таблица появилась в WooCommerce 3.x и используется для отчётов. Если у вас крупный магазин с тысячами заказов, отчёты в админке могут подтормаживать. Помогает индекс:

ALTER TABLE wp_wc_order_stats ADD INDEX idx_status_date (status, date_created);
ALTER TABLE wp_wc_order_stats ADD INDEX idx_customer_id (customer_id);

wp_wc_order_product_lookup

Ещё одна таблица из системы отчётов WooCommerce. Хранит данные о товарах в заказах. Без индексов по order_id и product_id отчёт по продажам может виснуть надолго:

ALTER TABLE wp_wc_order_product_lookup ADD INDEX idx_order_id (order_id);
ALTER TABLE wp_wc_order_product_lookup ADD INDEX idx_product_id (product_id);

wp_comments и wp_commentmeta

Отзывы к товарам хранятся в таблице комментариев. Если отзывов тысячи — фильтрация по товару и проверка статуса может быть медленной:

ALTER TABLE wp_comments ADD INDEX idx_comment_post_status (comment_post_ID, comment_approved, comment_type);

Полный список рекомендуемых индексов

Сводная таблица по ключевым индексам для WooCommerce:

Как безопасно добавить индексы

Перед любыми манипуляциями с базой — бэкап. Это аксиома. Даже если вы уверены в запросе на 100%, сделайте дамп базы. Через WP-CLI это одна команда:

wp db export backup-before-indexes.sql

Дальше — несколько правил безопасности:

• Добавляйте индексы в период низкой нагрузки. Процесс может занять от нескольких секунд до нескольких минут на больших таблицах. Во время построения индекса таблица будет заблокирована.
• Не добавляйте индексы «на всякий случай». Каждый индекс ускоряет SELECT, но замедляет INSERT и UPDATE. Для таблицы с частыми записями это критично.
• Проверяйте, нет ли индекса уже. Повторный запрос просто упадёт с ошибкой.
• Используйте формат DYNAMIC для таблиц InnoDB — это стандарт, но проверить стоит.

Посмотреть существующие индексы можно так:

SHOW INDEX FROM wp_postmeta;

Автоматизация: плагины для оптимизации БД

Если писать SQL вручную не хочется, есть инструменты:

• Index WP MySQL For Speed — плагин от разработчиков, которые разбираются в архитектуре WordPress. Он автоматически добавляет нужные индексы к основным таблицам. Можно включить и забыть.
• WP-Optimize — чистит мусор и оптимизирует таблицы, но индексы добавляет не все.
• Advanced Database Cleaner — хорош для удаления ревизий, спама, остатков удалённых плагинов.

Мой совет: начните с Index WP MySQL For Speed — он закрывает 80% потребностей. Остальное —เฉพированно, под конкретные запросы вашего магазина.

Что ещё влияет на скорость БД WooCommerce

Индексы — мощный инструмент, но не панацея. Вот что ещё стоит сделать:

• Перейти на InnoDB — если какие-то таблицы всё ещё на MyISAM, конвертируйте. InnoDB лучше работает с транзакциями и блокировками на уровне строк.
• Оптимизировать PHP-код. Один «тяжёлый» плагин может генерировать 200 запросов на страницу. Никакие индексы это не спасут.
• Настроить object cache — Redis или Memcached кэшируют результаты запросов в оперативной памяти. Повторные обращения к БД исключаются.
• Чистить ревизии и черновики. WooCommerce создаёт много служебных постов. Ревизии накапливаются. Установите лимит: define('WP_POST_REVISIONS', 5);
• Использовать HPOS (High-Performance Order Storage) — новая система хранения заказов WooCommerce, которая переносит заказы из wp_posts/wp_postmeta в отдельные оптимизированные таблицы. Это кардинальное улучшение.

Про HPOS стоит сказать подробнее. Раньше каждый заказ WooCommerce — это пост типа shop_order. Теперь заказы хранятся в собственных таблицах wp_wc_orders и wp_wc_orders_meta. Это снимает нагрузку с wp_postmeta и ускоряет админку на порядок. Включение HPOS — отдельная тема, но если вы на свежей версии WooCommerce — однозначно стоит рассмотреть.

Реальные результаты: что даёт индексация

Приведу пример из практики. Магазин электроники: 12 000 товаров, 45 000 заказов. Каталог загружался за 4–6 секунд. Админка «Все заказы» — за 8–12 секунд. После добавления индексов:

• Каталог с фильтрами: с 4.8 сек → 0.9 сек
• Страница «Заказы» в админке: с 11 сек → 1.5 сек
• Запрос на поиск товара по артикулу: с 2.3 сек → 0.05 сек

Никаких изменений в хостинге, плагинах или теме. Только индексы.

Когда лучше не трогать

Бывают ситуации, когда самостоятельная индексация — не лучшая идея:

• Вы не уверены, что делаете. Один неправильный запрос — и таблица может «лечь».
• Магазин на shared-хостинге с ограничениями. Некоторые хостеры блокируют ALTER TABLE.
• База уже оптимизирована плагином или хостером. Проверьте перед тем, как добавлять дубли.
• Проблема не в БД, а в коде. 300 запросов на страницу не спасёт ни один индекс.

В этих случаях лучше привлечь специалиста, который проведёт аудит запросов, проанализирует slow log и предложит точечное решение.

Итого: чек-лист оптимизации БД WooCommerce

1. Проанализируйте скорость запросов через Query Monitor или slow query log
2. Сделайте резервную копию базы данных
3. Добавьте индексы на wp_postmeta (meta_key + meta_value)
4. Добавьте индекс на wp_options (option_name)
5. Проиндексируйте таблицы отчётов WooCommerce
6. Включите HPOS для хранения заказов
7. Настройте object cache (Redis/Memcached)
8. Проверьте результат — замерьте время выполнения ключевых страниц

Оптимизация базы WooCommerce — это не «раз и забыл». Со временем таблицы растут, плагины добавляют новые данные, мета-ключи меняются. Раз в квартал полезно заглянуть в Query Monitor и убедиться, что ничего не раздулось.</