Highload-блоки в Битрикс: когда переходить и как работать

Сайт на Битрикс начинает тормозить, когда в справочнике городов накапливается 50 000 записей, а в таблице остатков — 200 000. Привычный инфоблок загружает в память всю структуру свойств, разделов и прав доступа, даже если вам нужна одна строка. Highload-блоки спроектированы для таких объёмов: минимальная обвязка, прямые запросы к таблице, никакой работы с разделами и сложными свойствами.

Чем highload-блоки отличаются от инфоблоков

Обычный инфоблок — это универсальная CMS-обёртка. У элемента есть активность, сортировка, разделы, множественные и файловые свойства, права доступа, история изменений. Каждый запрос элемента тянет за собой проверку прав, подгрузку метаданных, обработку дат активности. На десяти тысячах записей это работает, на ста — начинает скрипеть.

Highload-блок — таблица в базе с набором полей, обёрнутая минимальным API. Нет разделов, нет активности, нет файловых свойств и привязок к другим инфоблокам. Только пользовательские поля (UF_*), как у пользователей или групп. Запрос идёт напрямую через ORM, без лишних проверок.

Когда нужен переход на highload

Критерии для перехода — объём и характер работы с данными:

• В справочнике больше 10 000–15 000 записей, и он продолжает расти. Инфоблок ещё работает, но админка начинает подвисать.
• Данные используются для выборки и фильтрации, а не для публичного показа. Город в заказе, статус платежа, внешний ID из 1С — это кандидаты на highload.
• Нужна высокая скорость записи: логи, счётчики, очередь задач. Инфоблок тратит время на проверки и пересчёт, highload пишет напрямую.
• Вы готовы отказаться от файлов, привязок к другим сущностям и прав доступа на уровне элемента.

Не переходите на highload, если:

• Элементы выводятся в публичной части через компонент news.list — компонент заточен под инфоблоки.
• Нужны файловые поля или привязка к другим инфоблокам. Highload умеет только строки, числа, даты, булевы значения.
• В таблице меньше 5 000 записей и роста не предвидится. Выигрыш в скорости будет незаметен, а код усложнится.

Как создать highload-блок

Создать можно через админку («Настройки → Настройки продукта → Настройки модулей → Highload-блоки») или кодом. Через код надёжнее, если блок создаётся миграцией:

<?php
use Bitrix\Highloadblock\HighloadBlockTable;

$result = HighloadBlockTable::add([
    'NAME' => 'CityReference',
    'TABLE_NAME' => 'app_city_reference',
]);

if ($result->isSuccess()) {
    $hlblockId = $result->getId();
    // Добавляем пользовательские поля через CUserTypeEntity
    $fields = [
        [
            'ENTITY_ID' => 'HLBLOCK_' . $hlblockId,
            'FIELD_NAME' => 'UF_NAME',
            'USER_TYPE_ID' => 'string',
            'MANDATORY' => 'Y',
        ],
        [
            'ENTITY_ID' => 'HLBLOCK_' . $hlblockId,
            'FIELD_NAME' => 'UF_CODE',
            'USER_TYPE_ID' => 'string',
        ],
    ];
    
    $oUserTypeEntity = new CUserTypeEntity();
    foreach ($fields as $field) {
        $oUserTypeEntity->Add($field);
    }
}

После создания блока в базе появится таблица app_city_reference с полями ID, UF_NAME, UF_CODE. Битрикс добавит к ней ORM-класс, через который идёт вся работа.

Как работать с данными

API highload-блока похож на D7 ORM. Сначала получаем класс-сущность, потом вызываем методы выборки и изменения:

<?php
use Bitrix\Highloadblock\HighloadBlockTable;

// Получаем сущность по ID блока
$hlblock = HighloadBlockTable::getById($hlblockId)->fetch();
$entity = HighloadBlockTable::compileEntity($hlblock);
$entityDataClass = $entity->getDataClass();

// Выборка с фильтром и сортировкой
$result = $entityDataClass::getList([
    'select' => ['ID', 'UF_NAME', 'UF_CODE'],
    'filter' => ['UF_CODE' => 'msk'],
    'order' => ['UF_NAME' => 'ASC'],
    'limit' => 50,
]);

while ($row = $result->fetch()) {
    echo $row['UF_NAME'];
}

Добавление записи:

$result = $entityDataClass::add([
    'UF_NAME' => 'Москва',
    'UF_CODE' => 'msk',
]);

if (!$result->isSuccess()) {
    print_r($result->getErrorMessages());
}

Обновление и удаление — через ::update($id, $fields) и ::delete($id). Все методы возвращают объект Result с методами isSuccess() и getErrorMessages(), как в остальном D7 API.

Highload-блок не умеет в кеширование на уровне компонента. Если данные нужны на каждом хите, оборачивайте выборку в CPageCache или Data\Cache вручную.

Индексы и производительность

Битрикс создаёт таблицу без дополнительных индексов. Если фильтруете по полю UF_CODE на таблице в сто тысяч записей, база делает полный скан. Индекс добавляется вручную через SQL или миграцию:

CREATE INDEX ix_city_code ON app_city_reference(UF_CODE);

Проверяйте план запроса (EXPLAIN) после добавления индекса. На малых объёмах база может игнорировать индекс и сканировать таблицу — это нормально до определённого размера.

Когда что выбирать

Используйте инфоблок, если:

• элементы нужно показывать через стандартные компоненты news, catalog;
• нужны файловые поля, множественные свойства, привязки к другим сущностям;
• записей меньше 10 000, и они редко меняются;
• важна история изменений и права доступа на уровне элемента.

Используйте highload-блок, если:

• записей больше 15 000, или планируется рост до сотен тысяч;
• данные используются для фильтрации, выборки, связей, но не для прямого вывода;
• нужна высокая скорость записи: логи, счётчики, очередь;
• достаточно простых типов полей: строка, число, дата, булево значение.

Типичные ошибки

Забыли про индексы. Highload-блок на 100 000 записей без индексов работает медленнее инфоблока. Проверяйте план запроса и добавляйте индексы на поля, по которым фильтруете.

Пытаетесь использовать CIBlockElement::GetList. Методы старого API для работы с инфоблоками не видят highload-блоки. Только D7 API через compileEntity.

Создали файловое поле. Битрикс позволит создать UF-поле типа «файл», но работа с ним в highload-блоке ненадёжна: нет автоматической очистки при удалении записи, нет ресайза. Если нужны файлы, используйте инфоблок или храните только ID файла из b_file, управляя им вручную.

Кешируете через тегированный кеш инфоблока. Highload-блоки не интегрированы с системой тегированного кеша. Используйте Data\Cache с явным временем жизни или собственной логикой инвалидации.

Забыли проверить isSuccess(). Методы add и update не бросают исключения при ошибке валидации. Если не проверить результат, запись не добавится, и код продолжит работу с пустым ID.

Что дальше

После перехода на highload-блоки следите за размером таблицы и планами запросов. Если выборка начинает тормозить, проверьте индексы через SHOW INDEX FROM app_city_reference и добавьте недостающие. Для таблиц больше миллиона записей подумайте о партиционировании или выносе данных в отдельное хранилище — Redis для счётчиков, ClickHouse для логов. Highload-блоки закрывают 90% задач с большими объёмами в Битрикс, но на определённом масштабе упираются в возможности MySQL.