D7 ORM в 1С-Битрикс: как делать выборки и не создавать лишнюю нагрузку

D7 ORM в 1С-Битрикс — работа с данными и запросами

D7 в 1С-Битрикс даёт более современный подход к работе с модулями и данными. Но сам переход на ORM не делает запрос автоматически быстрым. Можно написать аккуратный код на новом API и всё равно получить тяжёлую выборку, если запросить лишние поля, выполнить запрос внутри цикла или загрузить тысячи строк без ограничения.

Поэтому при работе с ORM важно думать не только о синтаксисе, но и о том, какой SQL в итоге потребуется базе данных.

Когда ORM особенно удобна

ORM хорошо подходит для таблиц модулей и собственных сущностей, где структура данных описана явно. Запрос получается читаемым: видно select, filter, order, limit и runtime-поля. Такой код проще поддерживать, чем набор несвязанных SQL-фрагментов.

$result = SomeTable::getList([
    'select' => ['ID', 'NAME'],
    'filter' => ['=ACTIVE' => 'Y'],
    'order'  => ['ID' => 'DESC'],
    'limit'  => 20,
]);

Но даже здесь полезно выбирать только то, что реально используется дальше. Если на странице нужен ID и название, нет смысла получать все поля записи.

Главная ошибка — запрос внутри цикла

Классическая проблема выглядит безобидно: сначала выбирается список объектов, а затем для каждого выполняется ещё один запрос за связанными данными. На десяти элементах это незаметно, на нескольких сотнях превращается в сотни обращений к базе.

Лучше заранее собрать идентификаторы и сделать одну общую выборку, использовать связи ORM или сформировать структуру данных до начала вывода.

Используйте limit и фильтр как можно раньше

Если нужны последние 20 записей, не следует получать всю таблицу и обрезать массив в PHP. Ограничение должно попасть в сам запрос. То же относится к фильтрации: база данных должна вернуть именно необходимые строки, а не большой набор для последующей обработки приложением.

Runtime-поля полезны, но требуют контроля

Вычисляемые поля, выражения и связи позволяют решать сложные задачи одним запросом. Однако чем больше JOIN, группировок и вычислений появляется в выборке, тем важнее посмотреть фактический SQL и план выполнения. Иногда два простых запроса с понятным кешированием работают стабильнее одной универсальной конструкции.

ORM и инфоблоки

Для инфоблоков исторически используется старый API, но современные версии платформы развивают ORM-возможности и для этого направления. При выборе подхода нужно учитывать версию инфоблока, структуру свойств и конкретную задачу. Не стоит переписывать рабочий код только ради нового синтаксиса: смысл перехода появляется там, где он улучшает поддержку, структуру или производительность.

Кеширование остаётся важным

Даже оптимальная выборка не должна выполняться на каждом хите, если результат редко меняется. На публичных страницах ORM обычно работает вместе с кешированием компонента или отдельным кешем данных. После изменения сущности кеш должен корректно инвалидироваться.

Отдельно механизм кеширования и композита разобран в статье про кеширование в 1С-Битрикс.

Практический чек-лист выборки

получайте только необходимые поля;
не выполняйте одинаковые запросы внутри цикла;
используйте limit и точный filter;
проверяйте количество и тип JOIN;
не загружайте большой набор только ради последующей фильтрации в PHP;
кешируйте данные, которые не должны пересчитываться на каждом запросе;
на тяжёлых страницах измеряйте время SQL, а не оценивайте код визуально.

ORM помогает сделать слой данных понятнее, но производительность по-прежнему зависит от архитектуры запроса и объёма обрабатываемых данных.

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