Настройка составных индексов для каталога 1С-Битрикс

Корень проблемы: медленные запросы MySQL в каталоге

Страница каталога с фильтром в 1С-Битрикс может загружаться 5–10 секунд даже на мощном сервере. Причина — неэффективное выполнение запросов MySQL из-за отсутствия составных индексов. Мы сталкивались с этим десятки раз: на проектах с 20 000+ товаров EXPLAIN показывает type: ALL — полный скан миллионов строк. На одном из проектов интернет-магазина с 50 000 товаров время загрузки страницы списка товаров с фильтром по цене и бренду достигало 12 секунд. После добавления составного индекса на таблицу свойств время упало до 0.9 секунды. Замена одиночных индексов на составные ускоряет страницы в 3–10 раз, снижая CPU-нагрузку базы на 40–70%. Анализ slow log с помощью <cite>Percona Toolkit</cite> помогает выявить проблемные запросы.

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

Как определить, какие индексы нужны вашему каталогу?

Первый шаг — включить slow query log и собрать реальные запросы фильтра:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

После сбора логов за сутки-двое используем pt-query-digest из Percona Toolkit для группировки и ранжирования запросов по суммарному времени выполнения. Топ-10 запросов по времени — точки приложения усилий. Обычно это запросы к таблицам b_iblock_element, b_iblock_element_prop_s* и b_catalog_price с множественными JOIN.

Почему составные индексы эффективнее одиночных?

Правило левого префикса: индекс (iblock_id, active, section_id) работает для запросов по iblock_id, по iblock_id + active, по всем трём полям. Запрос только по active этот индекс не использует.

Кардинальность на первом месте: в составном индексе ставим поле с наибольшим числом уникальных значений первым — если только это не противоречит WHERE-условиям запроса. Для таблицы элементов инфоблока IBLOCK_ID идёт первым почти всегда.

Покрывающие индексы: если SELECT берёт только поля, входящие в индекс, MySQL читает индекс без обращения к данным таблицы (Using index в EXPLAIN). Для часто используемых запросов-счётчиков это даёт 5–10-кратное ускорение по сравнению с обычным индексом. Подробнее о покрывающих индексах можно прочитать на Wikipedia.

Индексы для типового каталога Битрикс

На основе анализа slow log и EXPLAIN мы выявляем отсутствующие индексы, индексы с низкой селективностью и дублирующиеся. Пример типовых добавлений:

-- Для таблицы свойств (строковые значения)
ALTER TABLE b_iblock_element_prop_s17
  ADD INDEX idx_filter_cover (IBLOCK_ELEMENT_ID, PROPERTY_42, PROPERTY_55, PROPERTY_61)
  ALGORITHM=INPLACE LOCK=NONE;

-- Для цен каталога
ALTER TABLE b_catalog_price
  ADD INDEX idx_price_active (CATALOG_GROUP_ID, PRICE, CURRENCY)
  ALGORITHM=INPLACE LOCK=NONE;

Все изменения выполняются без блокировки таблиц в продакшне. После создания индексов проверяем результат через EXPLAIN и pt-index-usage — убираем то, что не используется ни одним запросом за период наблюдения.

Сравнение типов индексов

На практике покрывающие индексы в 5–10 раз быстрее одиночных при фильтрации по нескольким свойствам.

Проверка эффективности индексов после настройки

Данные получены на проекте с 25 000 товаров и 10 свойствами в фильтре. Средняя экономия на инфраструктуре после настройки индексов существенна, а один клиент после настройки отказался от дополнительного сервера. Время загрузки страницы сокращается на 3–10 секунд, что при 1000 посетителей в день даёт заметную экономию времени.

Процесс настройки индексов

1. Аудит slow log — сбор логов, группировка, ранжирование запросов по времени.
2. Проектирование индексов — создание составных, покрывающих, устранение дублирующихся.
3. Создание индексов — через online DDL (ALGORITHM=INPLACE LOCK=NONE) без остановки продакшна.
4. Тестирование — повторный EXPLAIN и pt-query-digest для подтверждения эффекта.
5. Документация — описание всех изменений и рекомендации по мониторингу.

Что входит в работу

• Детальный отчёт по результатам аудита slow log с указанием проблемных запросов.
• Проектирование и создание индексов с учётом вашей схемы данных.
• Тестирование производительности до/после с предоставлением метрик.
• Документация по новым индексам и рекомендации по дальнейшему мониторингу.
• Консультационная поддержка в течение 2 недель после завершения.

Опыт наших инженеров (более 10 лет и 50+ проектов на Битрикс) гарантирует совместимость с вашей архитектурой. Получите бесплатный анализ slow log вашего проекта — свяжитесь с нами, и мы подберём оптимальную конфигурацию.

Закажите консультацию по индексации — мы подготовим план ускорения вашего каталога.