Когда в интернет-магазине на WooCommerce несколько сотен товаров, проблемы с производительностью базы данных часто остаются незаметными. Но при росте каталога до 100 000 товаров ситуация меняется: фильтры начинают работать по несколько секунд, поиск замедляется, страницы категорий становятся тяжелее, а нагрузка на MySQL/MariaDB растёт даже при относительно небольшом количестве посетителей.
Особенно сложными становятся запросы, которые одновременно учитывают категории, атрибуты, цены, остатки, вариации, пользовательские поля и сортировку.
В этой статье разберём, почему WooCommerce начинает тормозить на больших каталогах и какие подходы позволяют оптимизировать SQL-запросы без отказа от стандартной архитектуры WordPress.
Почему каталог из 100 000 товаров — это проблема для WooCommerce
WooCommerce хранит товары в основном средствами WordPress. Товар — это запись в wp_posts, а дополнительные характеристики, цены, остатки и другие значения часто находятся в wp_postmeta.
На небольшом объёме данных такой подход удобен и практически незаметен. Однако у wp_postmeta есть принципиальная особенность: это универсальная таблица «ключ → значение».
Условный товар может иметь десятки записей:
post_id | meta_key | meta_value
---------------------------------------
10001 | _price | 14990
10001 | _stock_status | instock
10001 | _sku | ABC-001
10001 | _weight | 1.5
...
Для 100 000 товаров это уже миллионы строк в wp_postmeta.
И если запрос должен найти товары одновременно:
- из определённой категории;
- с определённым атрибутом;
- в заданном диапазоне цен;
- только в наличии;
- с сортировкой по цене,
база данных может выполнять большое количество операций над огромным объёмом данных.
Главная проблема — не количество товаров само по себе
100 000 товаров для MySQL — не экстремальный объём. При правильной структуре данных и индексах такая база может работать очень быстро.
Проблема обычно возникает из-за сочетания нескольких факторов:
- большого количества записей в
wp_postmeta; - запросов с множественными
JOIN; - фильтрации по
meta_keyиmeta_value; - сортировки больших промежуточных выборок;
LIKE '%строка%';- большого количества
OR; - неэффективной пагинации;
- отсутствия подходящих индексов;
- выполнения тяжёлых запросов на каждом HTTP-запросе;
- использования
WP_Queryдля задач, которые фактически требуют специализированного поискового индекса.
Поэтому оптимизация должна начинаться не с попытки «ускорить SQL», а с анализа того, какие данные, где и зачем запрашиваются.
Шаг 1. Сначала смотрим реальный SQL
Одна из распространённых ошибок — оптимизировать код на основании предположений.
Например, разработчик видит медленный фильтр и сразу добавляет кеширование. Но причина может находиться в SQL-запросе, который делает полный просмотр миллионов строк.
Для анализа полезно использовать:
EXPLAIN
SELECT ...
А для более глубокого анализа в современных версиях MySQL:
EXPLAIN ANALYZE
SELECT ...
Нужно смотреть не только на итоговое время выполнения, но и на:
- количество обработанных строк;
- используемые индексы;
- типы
JOIN; - наличие
Using temporary; - наличие
Using filesort; - фактический порядок выполнения операций.
Если запрос возвращает 50 товаров, но для этого база обрабатывает сотни тысяч или миллионы строк, именно здесь находится одна из основных точек оптимизации.
Шаг 2. Осторожнее с wp_postmeta
Классический пример проблемного запроса:
SELECT p.ID
FROM wp_posts p
JOIN wp_postmeta price
ON price.post_id = p.ID
JOIN wp_postmeta stock
ON stock.post_id = p.ID
WHERE p.post_type = 'product'
AND price.meta_key = '_price'
AND price.meta_value BETWEEN '1000' AND '5000'
AND stock.meta_key = '_stock_status'
AND stock.meta_value = 'instock';
На первый взгляд запрос вполне логичен.
Но если подобных фильтров становится пять или десять, таблица wp_postmeta подключается многократно. Каждый дополнительный JOIN потенциально увеличивает объём промежуточных данных.
Кроме того, meta_value хранится как строковое значение, хотя цена или количество на складе фактически являются числами.
Индексы помогают, но не решают архитектурную проблему
Индексация — один из первых инструментов оптимизации.
Например, индекс по комбинации:
(meta_key, meta_value, post_id)
может значительно сократить объём данных, который приходится просматривать.
Однако универсального индекса, который мгновенно ускорит любой WooCommerce-запрос, не существует.
Перед созданием индекса необходимо посмотреть реальный план выполнения запроса.
Особенно важно помнить, что индексы:
- занимают место;
- увеличивают стоимость операций
INSERTиUPDATE; - могут не использоваться оптимизатором;
- не устраняют проблемы неудачной структуры запроса.
Поэтому принцип «добавим индексов побольше» — плохая стратегия.
Шаг 3. Не фильтровать всё через postmeta
Если каталог содержит 100 000 товаров и пользователи постоянно фильтруют его по цене, бренду, наличию и другим параметрам, хранить абсолютно все данные только в wp_postmeta становится неудобно с точки зрения производительности.
Для часто используемых структурированных данных можно рассмотреть отдельную таблицу.
Например:
CREATE TABLE product_catalog_index (
product_id BIGINT UNSIGNED NOT NULL,
price DECIMAL(12,2),
stock_status TINYINT,
brand_id BIGINT UNSIGNED,
category_id BIGINT UNSIGNED,
PRIMARY KEY (product_id),
INDEX idx_price (price),
INDEX idx_stock (stock_status),
INDEX idx_brand (brand_id),
INDEX idx_category (category_id)
);
Конкретная структура зависит от проекта.
Смысл подхода заключается в том, что база получает специализированный индекс для каталога вместо попытки использовать универсальную wp_postmeta для всех сценариев.
Это особенно актуально для магазинов со сложной системой фильтрации.
Шаг 4. Учитываем HPOS и современные возможности WooCommerce
При оптимизации большого WooCommerce-магазина нельзя рассматривать архитектуру как неизменную.
В новых версиях WooCommerce появились специализированные таблицы и механизмы хранения данных, которые позволяют уменьшить зависимость от универсальной структуры WordPress.
Например, при работе с заказами важную роль играет High-Performance Order Storage (HPOS). Однако HPOS не решает автоматически проблему производительности каталога: товары, атрибуты и каталог имеют свою специфику.
Поэтому при модернизации проекта важно разделять:
- хранение заказов;
- хранение товарных данных;
- поиск;
- фильтрацию;
- индексацию;
- кеширование.
Каждая задача может требовать своего решения.
Шаг 5. Не использовать OFFSET для глубокой пагинации
Ещё одна распространённая проблема — пагинация вида:
SELECT ...
FROM ...
ORDER BY id
LIMIT 50 OFFSET 50000;
Чем глубже пользователь переходит по страницам, тем больше строк базе приходится пропускать.
Для больших каталогов эффективнее может быть keyset pagination.
Например:
SELECT id, name, price
FROM products
WHERE id > 50000
ORDER BY id
LIMIT 50;
Вместо:
LIMIT 50 OFFSET 50000
база сразу ищет записи после известного значения индекса.
Для каталога это особенно полезно при реализации:
- бесконечной прокрутки;
- API;
- экспорта;
- фоновой обработки;
- больших списков товаров.
Шаг 6. Сортировка тоже должна быть продумана
Запрос:
SELECT ...
FROM products
WHERE ...
ORDER BY price ASC
LIMIT 50;
может выполняться быстро, если структура таблицы и индекс позволяют базе получить данные уже в нужном порядке.
Но если сначала формируется огромный набор данных из нескольких JOIN, а затем MySQL должна его сортировать, появляется дорогостоящая операция.
При анализе EXPLAIN стоит обратить внимание на:
Using filesort
Сам по себе Using filesort не означает автоматически катастрофу. Но если он применяется к огромному промежуточному набору данных, это повод проверить запрос и индексы.
Шаг 7. Осторожно с LIKE
Поиск:
WHERE name LIKE '%iphone%'
плохо масштабируется для обычного B-tree-индекса.
Начальный wildcard:
%iphone%
не позволяет эффективно использовать стандартный индекс для поиска по началу строки.
Если каталог требует полноценного поиска по:
- названию;
- SKU;
- описанию;
- бренду;
- характеристикам,
стоит рассмотреть специализированный поисковый индекс.
В зависимости от требований проекта это может быть:
- полнотекстовый индекс MySQL;
- отдельный поисковый движок;
- специализированный индекс каталога;
- внешний search-сервис.
Для 100 000 товаров полноценный поиск уже вполне может быть отдельной подсистемой.
Шаг 8. Не заставляем базу каждый раз собирать один и тот же каталог
Даже хорошо оптимизированный SQL не обязательно должен выполняться на каждый запрос пользователя.
Если 500 пользователей одновременно открывают одну и ту же категорию:
/brand/samsung/
нет смысла заставлять базу 500 раз выполнять одинаковую тяжёлую выборку.
На уровне приложения можно использовать:
- object cache;
- Redis;
- page cache;
- fragment cache;
- кеш результатов фильтрации;
- CDN для статических ресурсов.
Например, результат запроса с определённым набором фильтров можно кешировать по ключу:
catalog:samsung:instock:price-1000-5000:page-1
Но кеширование должно быть частью архитектуры, а не способом скрыть неэффективный SQL.
Шаг 9. Следим за количеством SQL-запросов
Иногда проблема заключается не в одном очень медленном запросе, а в сотнях небольших запросов.
Типичный сценарий:
- получить 50 товаров;
- для каждого товара запросить цену;
- отдельно получить остаток;
- отдельно получить атрибуты;
- отдельно получить изображения;
- повторить всё для связанных товаров.
Получается классическая проблема N+1 queries.
Условно:
1 запрос → список товаров
50 запросов → данные каждого товара
50 запросов → дополнительные данные
В результате страница может сделать сотни обращений к базе.
Нужно стремиться к пакетной загрузке данных и проверять количество запросов профайлером.
Шаг 10. WooCommerce-фильтры лучше проектировать как отдельную систему
Если пользователю доступны десятки фильтров:
Бренд
Цена
Размер
Цвет
Материал
Наличие
Рейтинг
Скидка
Производитель
...
не стоит автоматически превращать каждую галочку в очередной JOIN wp_postmeta.
На больших каталогах фильтрация должна иметь собственную модель данных.
Возможная архитектура:
WooCommerce
│
├── Основные данные товаров
│
├── Индекс каталога
│ ├── цена
│ ├── наличие
│ ├── бренд
│ └── характеристики
│
├── Поисковый индекс
│
└── Cache
└── Redis
При изменении товара фоновой процесс обновляет необходимые индексы.
Пользовательский запрос при этом обращается не ко всей WordPress-модели данных, а к оптимизированному представлению каталога.
Что делать с вариативными товарами
Вариативные товары — отдельный источник сложности.
Один родительский товар может иметь десятки или сотни вариаций. Если в каталоге десятки тысяч таких товаров, количество записей и связей быстро увеличивается.
Например:
Футболка
├── S / Black
├── M / Black
├── L / Black
├── S / White
├── M / White
└── ...
Если фильтр должен определить доступные комбинации атрибутов, цена и остаток могут находиться на уровне вариации, а отображаемый товар — на уровне родительского продукта.
Поэтому запросы нужно проектировать с учётом того, на каком уровне находится фильтруемое значение.
Иногда эффективнее заранее построить индекс доступных значений, чем каждый раз вычислять их через цепочку JOIN.
Как диагностировать проблему на реальном проекте
Мы обычно рекомендуем двигаться от измерений к изменениям.
1. Найти самые дорогие запросы
Сначала определяем:
- какие SQL-запросы выполняются дольше всего;
- сколько раз они вызываются;
- сколько строк обрабатывают;
- какие страницы вызывают максимальную нагрузку.
2. Посмотреть EXPLAIN ANALYZE
Нужно понять, где база тратит время:
JOIN
↓
Filtering
↓
Sorting
↓
Temporary table
↓
Result
3. Проверить индексы
Сравниваем:
SHOW INDEX FROM wp_postmeta;
с реальными условиями поиска.
4. Проверить структуру данных
Если критически важный параметр находится в wp_postmeta и используется в каждом каталожном запросе, возможно, проблема уже архитектурная.
5. Проверить кеш
Даже оптимальный SQL не должен без необходимости выполняться тысячи раз для одинаковых параметров.
Какие оптимизации дают наибольший эффект
Для каталога на 100 000 товаров обычно полезно двигаться в следующем порядке:
| Уровень | Что проверяем |
|---|---|
| SQL | EXPLAIN, EXPLAIN ANALYZE, JOIN, WHERE, ORDER BY |
| Индексы | соответствие индексам реальных условий выборки |
| Данные | что хранится в postmeta, а что стоит вынести |
| Архитектура | нужен ли отдельный каталоговый индекс |
| Поиск | подходит ли MySQL для полнотекстового поиска |
| Кеш | Redis/object cache и кеш результатов |
| Приложение | N+1 и количество SQL-запросов |
| Пагинация | отказ от глубокого OFFSET |
| Фоновые процессы | обновление индексов и тяжёлые операции вне HTTP |
Типичные ошибки
«Добавим индекс — и всё заработает»
Не всегда. Если SQL архитектурно неудачен, индекс может дать минимальный эффект.
«У нас всего 100 000 товаров, MySQL должна справляться»
Сама цифра 100 000 не является проблемой. Важнее количество связанных записей, структура запросов и частота их выполнения.
«Кеш всё исправит»
Кеш может резко снизить нагрузку, но после очистки кеша медленный запрос всё равно останется медленным.
«Будем использовать только стандартный WP_Query»
Для простых страниц каталога это нормально. Но сложная аналитика, поиск и многомерная фильтрация могут требовать более специализированного SQL или отдельного индекса.
«Сделаем один огромный SQL-запрос»
Большой запрос не обязательно эффективнее нескольких правильно спроектированных операций. Нужно оптимизировать не количество строк SQL-кода, а план выполнения и архитектуру обработки данных.
Практический принцип
Для большого WooCommerce-каталога полезно разделять две задачи:
CMS-хранение — данные должны удобно редактироваться WordPress и WooCommerce.
Каталоговый поиск — данные должны быстро фильтроваться и сортироваться.
Они не обязательно должны решаться одной и той же таблицей.
Именно этот переход от модели «WordPress хранит всё и сам ищет всё» к модели «WordPress — источник данных, каталог — оптимизированный индекс» часто становится главным архитектурным улучшением при росте проекта.
Итог
Каталог WooCommerce на 100 000 товаров вполне может работать быстро. Но для этого недостаточно просто увеличить ресурсы сервера.
Основные точки оптимизации:
- анализировать реальные SQL-запросы;
- использовать
EXPLAIN ANALYZE; - правильно проектировать индексы;
- минимизировать тяжёлые
JOINсwp_postmeta; - избегать N+1 запросов;
- оптимизировать сортировку и пагинацию;
- отделять поиск от стандартного хранения данных;
- использовать кеширование;
- при необходимости создавать специализированный индекс каталога;
- обновлять тяжёлые индексы и агрегаты в фоне.
Если каталог уже содержит десятки или сотни тысяч товаров, оптимизацию лучше проводить не методом проб и ошибок, а начиная с профилирования: сначала измеряем, затем находим узкое место, после этого меняем SQL или архитектуру и снова измеряем результат.
Именно такой подход позволяет ускорить WooCommerce-каталог без хаотичного добавления индексов, плагинов и серверных ресурсов.
