Как создать Highload-блок на 1С-Битрикс: справочники, свойства и вывод на сайте

Бренды, города и таблицы соответствий лежат в свойствах инфоблока каталога - умный фильтр и админка тормозят, заказчик просит "вынести справочник". Highload-блок в 1С-Битрикс: Управление сайтом - это отдельная таблица в базе с удобной админкой, а не "инфоблок, только быстрее". Ниже - полный цикл: когда HL уместен, создание в админке, поля UF_*, вывод через D7 ORM и индексы MySQL, чтобы 20 000 записей не убивали фильтр.

Highload-блок - плоский справочник в своей таблице MySQL с полями UF_* и формой в админке CMS. Создайте блок в "Контент → Highload-блоки", настройте HLBLOCK_ID, заполните данные, читайте через HighloadBlockTable::compileEntity и getList. После 5-10 тысяч строк добавьте SQL-индексы на поля фильтра вручную - Битрикс их не ставит сам.

Bitrix24 - CRM и портал для задач, не наш продукт. Статья про коробочную CMS на вашем сервере. Если вы искали настройку справочников в облачной CRM - это другой интерфейс; здесь только "1С-Битрикс: Управление сайтом".

В выдаче много D7-сниппетов с HL=1 и мало связки "админка → код → индексы". Ниже - пять блоков с чек-листами и типовыми ошибками с dev.1c-bitrix.ru.

Оцените, когда Highload оправдан вместо инфоблока

Инфоблок - контент с разделами, SEO-полями, картинками и привязкой к шаблонам. Highload-блок (HL) - плоская таблица-справочник: бренды, города, коды складов, логи событий. Без иерархии разделов и без "страницы элемента" на сайте.

Если умный фильтр на Битрикс тормозит из-за свойств типа "список" с тысячами значений - кандидат на вынос в HL. В каталоге остаётся только ссылка на код справочника, а не "свалка" всех брендов в одном свойстве.

Делайте: выносите в HL фильтруемые справочники от 3-5 тысяч строк и логи без SEO. Не делайте: не дублируйте товары или новости в HL "ради скорости" - для контента с разделами нужен инфоблок.

Создайте HL-блок в админке CMS

Модуль "Highload-блоки" должен быть установлен. Путь: Контент → Highload-блоки → Добавить. Поля HL - пользовательские поля ядра с объектом HLBLOCK_ID, не "свойства элемента" инфоблока.

1. Укажите название сущности латиницей с заглавной буквы, например BrandDirectory.
2. Задайте TABLE_NAME в snake_case: только строчные буквы, цифры и underscore, например b_hlbd_brands. Имя должно быть уникальным в базе.
3. Заполните языковые названия для админки - так редакторы увидят "Справочник брендов", а не Latin-код.
4. Настройте права доступа на закладке "Права" (доступна с версии 17.0.0 модуля): кто может добавлять и править записи.
5. Запишите ID блока после сохранения - он понадобится в коде. Храните в constants.php проекта, не копируйте HL=1 с Habr.

Дальше добавьте поля через "Пользовательские поля" объекта HLBLOCK_ID: UF_NAME (строка), UF_XML_ID (строка, уникальный код для обмена), UF_SORT (число), UF_ACTIVE (да/нет). Для логотипа бренда - UF_FILE (файл). Префикс UF_ обязателен: так ядро понимает, что это колонки таблицы HL.

Делайте: сразу после создания зафиксируйте ID и TABLE_NAME в документации проекта. Не делайте: не переименовывайте TABLE_NAME на проде без миграции - код с compileEntity перестанет находить данные.

Заполните справочник и настройте импорт

Записи добавляются в "Контент → Highload-блоки → [ваш блок] → Элементы". Для сотен строк хватит ручного ввода. Для тысяч - штатный импорт/экспорт модуля или CSV через админку.

Схема связи с каталогом:
HL-справочник (UF_XML_ID) → свойство товара "Справочник" или строка с кодом → умный фильтр по коду → быстрая выборка без раздувания свойств IB

Если каталог связан с 1С, синхронизируйте UF_XML_ID с кодами номенклатуры - подробнее в гайде по интеграции 1С с сайтом на Битрикс. В свойстве товара храните XML_ID бренда, а не текст "Nike" - так проще обновлять названия в одном месте.

Делайте: перед массовым импортом сделайте бэкап базы и проверьте уникальность UF_XML_ID. Не делайте: не заливайте 50 000 строк без теста на стенде - админка и первые getList без индексов покажут реальную скорость только после наполнения.

Подключите вывод на сайте через D7 ORM

D7 ORM - слой работы с базой в Битрикс через методы класса вместо старых CIBlockElement. Для HL: подключить модуль → getById → compileEntity → getDataClass → getList.

<?php
use Bitrix\Main\Loader;
use Bitrix\Highloadblock\HighloadBlockTable;

Loader::includeModule('highloadblock');

$hlblock = HighloadBlockTable::getById(BRAND_HL_ID)->fetch;
if (!$hlblock) {
 return; // блок не найден - проверьте ID в админке
}
$entity = HighloadBlockTable::compileEntity($hlblock);
$dataClass = $entity->getDataClass;

$rows = $dataClass::getList([
 'select' => ['ID', 'UF_NAME', 'UF_XML_ID'],
 'filter' => ['=UF_ACTIVE' => 1],
 'order' => ['UF_SORT' => 'ASC'],
 'limit' => 50,
])->fetchAll;

compileEntity собирает PHP-класс для таблицы HL. Битый ID или удалённый блок дают Invalid highloadblock description. Типичная ошибка: getById(1) с туториала, на проде ID=4. На практике кэшируйте $dataClass в static или Bitrix\Main\Data\Cache, не compileEntity на каждый hit.

Для списка брендов на публичной странице интернет-магазина на Битрикс оберните getList в кэш с TTL 3600 секунд и тегами инвалидации при изменении HL. Готового универсального компонента "вывести любой HL" в ядре нет - обычно пишут свой include или result_modifier.

Делайте: проверяйте getById->fetch перед compileEntity и логируйте пустую выборку на стенде. Не делайте: не наследуйте DataClass от compileEntity без переопределения getEntity - на форуме это даёт Unknown field definition.

Проверьте индексы, права и производительность

После 5-10 тысяч строк запросы по UF_NAME или UF_XML_ID без индекса превращаются в full scan - секунды вместо миллисекунд. Битрикс не создаёт индексы на UF_* автоматически. Добавьте их вручную через phpMyAdmin или консоль MySQL:

ALTER TABLE b_hlbd_brands ADD INDEX ix_xml_id (UF_XML_ID);
ALTER TABLE b_hlbd_brands ADD INDEX ix_name (UF_NAME);

Имя таблицы смотрите в карточке HL (TABLE_NAME). После ADD INDEX проверьте EXPLAIN для типового фильтра каталога - type должен быть ref или range, а не ALL.

Финальный чек-лист: CRUD работает, права настроены, getList укладывается в 200 ms, ID и TABLE_NAME задокументированы. Сложные FK и составные индексы иногда проще в custom DataManager - HL выигрывает, когда нужна админка без CRUD с нуля.

Делайте: после выноса справочника прогоните фильтр каталога под нагрузкой и заложите поддержку сайта на Битрикс на мониторинг медленных запросов. Не делайте: не считайте HL "магическим ускорителем" без индексов - это обычная MySQL-таблица с формой в админке.

Нужен аудит структуры каталога и вынос тяжёлых справочников под ваш обмен с 1С - обсудим задачу. Примеры магазинов с оптимизированными справочниками - в портфолио.

Автор: Максим Мольков, Senior-разработчик 1С-Битрикс, 8+ лет в веб-разработке.
Источники: dev.1c-bitrix.ru.

Частые вопросы