Фасетный индекс: как ускорить умный фильтр

Фасетный индекс — это денормализованная таблица, в которой Битрикс заранее раскладывает значения свойств товаров. Именно он превращает умный фильтр из медленного набора JOIN-ов в мгновенную выборку. Разбираем, как индекс устроен, когда он тормозит и как поддерживать его в рабочем состоянии на каталоге в десятки тысяч SKU.

Что такое фасетный индекс и зачем он нужен

Умный фильтр в 1С-Битрикс работает поверх свойств инфоблока (модуль iblock). Без индекса каждый запрос фильтра вынужден соединять таблицу элементов с таблицами значений свойств — b_iblock_element_property и SKU торговых предложений. На каталоге в 30–50 тысяч товаров с десятком фильтруемых свойств это десятки JOIN-ов и полные сканы, из-за которых страница каталога открывается по 2–5 секунд.

Фасетный индекс решает проблему денормализацией. Битрикс заранее вычисляет, какие значения свойств есть у каждого товара, и складывает их в отдельную плоскую таблицу вида b_iblock_element_prop_sN и фасетную b_iblock_element_facet (где N — ID инфоблока). Теперь фильтр — это выборка по индексированным столбцам одной таблицы, без тяжёлых соединений.

• Быстрая выборка товаров по любой комбинации фильтров.
• Мгновенный подсчёт количества товаров в каждой позиции фильтра (те самые счётчики у чекбоксов).
• Корректное «гашение» недоступных значений — свойств, по которым в текущей выборке ничего нет.

Как включить фасетный индекс

Индекс включается на уровне инфоблока каталога. Зайдите в Контент → Каталог → Типы каталогов, откройте нужный инфоблок и перейдите на вкладку «Свойства» либо на страницу настройки умного фильтра. Внизу списка свойств есть блок управления фасетным индексом.

1. Отметьте свойства, которые реально участвуют в фильтре, галочкой «В умном фильтре» — только они попадут в индекс.
2. Нажмите кнопку «Изменить индекс» (в старых редакциях — «Пересоздать индекс»).
3. Дождитесь завершения пошаговой индексации: система обходит все элементы и заполняет фасетные таблицы.

После построения в списке инфоблока появляется статус индекса и дата последнего обновления — по ним удобно контролировать актуальность.

Какие свойства попадают в индекс

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

Свойства торговых предложений (SKU) тоже индексируются — например, размер и цвет. Битрикс проецирует их на родительский товар, чтобы фильтр по цвету находил товар, у которого хотя бы одно предложение подходит.

Как индекс поддерживается в актуальном состоянии

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

• Ручное редактирование в админке — индекс по элементу обновляется автоматически при сохранении.
• Обмен с 1С — при импорте каталога через 1c_catalog индекс дописывается по мере загрузки элементов, но при массовой выгрузке это заметно нагружает базу.
• Массовые правки через API (CIBlockElement::Update, свои скрипты) — вот здесь чаще всего индекс расходится с данными.

Пересборка индекса и автоматизация

Полная пересборка через админку удобна для разовой операции, но на большом каталоге занимает минуты и делается в браузере пошагово. Для регулярного обслуживания её выносят в код и агент/крон.

Пересобрать индекс программно можно через класс модуля iblock:

\Bitrix\Iblock\PropertyIndex\Manager::createIndexer($iblockId) — создаёт индексатор, далее вызываются методы startIndex(), continueIndex() и endIndex() в цикле, пока пересборка не завершится.

• Оберните пересборку в свой скрипт и запускайте по крону после ночного обмена с 1С.
• На проде выполняйте пересборку в низкий трафик — во время построения фильтр может отдавать неполные данные.
• Для инкрементальных правок достаточно точечного обновления элемента, полная пересборка нужна при смене состава фильтруемых свойств.

Диагностика: когда фильтр всё равно тормозит

Даже с индексом каталог может открываться медленно. Прежде чем грешить на фасет, проверьте, где именно уходит время.

1. Включите отладку SQL в панели разработчика Битрикс и посмотрите, обращается ли фильтр к b_iblock_element_facet или всё ещё делает JOIN-ы по b_iblock_element_property. Второе означает, что индекс не построен или отключён.
2. Убедитесь, что в компоненте bitrix:catalog.smart.filter и bitrix:catalog.section не выключено использование фасетного индекса.
3. Проверьте кэш: умный фильтр и листинг должны кэшироваться, иначе счётчики пересчитываются на каждый запрос.
4. Смотрите на медленные запросы MySQL (slow_query_log) — часто узкое место не фильтр, а сортировка или вывод остатков и цен.

Типовые причины «медленного фильтра при живом индексе»: отсутствие кэширования компонентов, тяжёлые пользовательские свойства в выводе, нехватка оперативной памяти под innodb_buffer_pool_size и параллельный ресурсоёмкий обмен с 1С.

Практические рекомендации для больших каталогов

На каталогах от нескольких десятков тысяч SKU есть набор приёмов, которые снимают большинство проблем ещё до того, как они проявятся у покупателей.

• Минимизируйте состав фильтра. Держите в умном фильтре только свойства, по которым люди реально ищут. Каждое лишнее свойство — это дополнительные данные в фасете и медленнее пересборка.
• Используйте «Список» вместо «Строки». Списочные свойства дают компактный индекс и корректное гашение вариантов.
• Разнесите обмен и пересборку по времени. Сначала полный импорт из 1С, затем отдельным шагом — пересборка индекса, а не одновременно.
• Мониторьте дату индекса. Если она отстаёт от последнего обмена — фильтр показывает устаревшую картину.
• Не отключайте события iblock ради скорости импорта без последующей ручной пересборки индекса.

Отдельно стоит следить за инфраструктурой БД: фасетный индекс эффективен только тогда, когда его таблицы помещаются в буфер InnoDB и не вытесняются другими запросами.

Итог

Фасетный индекс — это то, что делает умный фильтр в 1С-Битрикс пригодным для реального магазина. Включите его для каждого инфоблока, оставьте в фильтре только нужные свойства, настройте регулярную пересборку после обмена с 1С и следите за актуальностью индекса. Тогда фильтрация будет мгновенной даже на десятках тысяч товаров, а счётчики у чекбоксов — правильными.

Если каталог растёт, обмен с 1С «роняет» индекс или фильтр тормозит несмотря на все настройки, мы помогаем разобраться: находим узкое место, настраиваем корректную пересборку, кэширование и параметры БД. Это наши профильные задачи по ускорению магазина, интеграции с 1С и поддержке проектов на Битрикс.