Как оптимизировать запрос динамического списка в 1С:Предприятие 8.3

← На главную

Работа с динамическими списками в 1С требует особого подхода к написанию запросов. В отличие от обычных отчетов, динамический список предназначен для быстрого отображения данных порциями. Если запрос написан неоптимально, пользователь столкнется с "фризами" при прокрутке или долгим открытием формы. Рассмотрим подробнее основные методы оптимизации, которые помогут сделать работу со списками максимально плавной.

Использование оператора ССЫЛКА вместо ТИПЗНАЧЕНИЯ

Разберем типичную ситуацию, когда в запросе необходимо проверить тип ссылки. Часто начинающие разработчики используют конструкцию ТИПЗНАЧЕНИЯ. Проанализируем пример:


// Не рекомендуемый вариант
ГДЕ
    ТИПЗНАЧЕНИЯ(ЗадачаИсполнителя.БизнесПроцесс) = ТИП(БизнесПроцесс.СогласованиеЗаявки)

С точки зрения производительности СУБД (SQL) разница между ТИПЗНАЧЕНИЯ и ССЫЛКА может быть минимальной, так как обе конструкции в итоге проверяют поле с идентификатором типа. Однако, согласно стандартам разработки фирмы "1С", рекомендуется использовать оператор ССЫЛКА. Это делает код более читаемым и снижает вероятность ошибок при работе с составными типами данных. Посмотрим на правильный вариант:


// Рекомендуемый вариант
ГДЕ
    ЗадачаИсполнителя.БизнесПроцесс ССЫЛКА БизнесПроцесс.СогласованиеЗаявки

Важный момент: Использование ССЫЛКА позволяет платформе более эффективно строить план запроса, особенно когда речь идет об индексируемых полях.

Проблема использования СГРУППИРОВАТЬ ПО в динамических списках

Одной из самых серьезных ошибок при проектировании динамического списка является использование СГРУППИРОВАТЬ ПО или ВЫБРАТЬ РАЗЛИЧНЫЕ. Выясним причину, почему это замедляет работу.

Когда динамический список отображает данные, платформа оборачивает ваш текст запроса во внешний запрос с использованием инструкции TOP (для получения порции строк, например, 45). Если в вашем внутреннем запросе есть группировка по всем полям, СУБД вынуждена сначала выполнить полную группировку всех данных в таблице (миллионы строк), и только потом отобрать первые 45. Это сводит на нет все преимущества динамического считывания.

Рассмотрим, как можно избежать группировки:

Пересмотрите соединения: Если группировка используется для устранения дублей, возникающих из-за ЛЕВОЕ СОЕДИНЕНИЕ, попробуйте заменить соединение на обращение через точку (если это возможно) или на вложенный запрос в списке полей выбора.
Коррелированные подзапросы: Вместо соединения с большой таблицей и последующей группировки, попробуйте получить нужное значение через подзапрос прямо в секции ВЫБРАТЬ.

Индексирование временных таблиц

Часто возникает вопрос: нужно ли индексировать поля во временных таблицах (ВТ), если динамический список считывает данные порциями? Ответ зависит от структуры запроса. Если основной запрос списка соединяется с ВТ, то индекс по полю соединения критически необходим.

Проанализируем ситуацию: даже если список читает по 45 строк, СУБД при каждом таком чтении выполняет соединение таблиц. Без индекса во временной таблице SQL-сервер будет выполнять полное сканирование (Table Scan) этой таблицы для каждой строки основного запроса. Если в ВТ более 100 записей, отсутствие индекса приведет к заметным задержкам.

Пример правильного создания ВТ с индексом:


ВЫБРАТЬ
    Исполнители.Ссылка КАК Исполнитель
ПОМЕСТИТЬ ВТ_Исполнители
ИЗ
    Справочник.ВнешниеПользователи КАК Исполнители
ГДЕ
    Исполнители.Активен
;
////////////////////////////////////////////////////////////////////////////////
ИНДЕКСИРОВАТЬ ПО
    Исполнитель
;

Коррелированные подзапросы vs Временные таблицы

В обычных отчетах временные таблицы — это "золотой стандарт". Однако в динамических списках ситуация иная. Рассмотрим применение коррелированных подзапросов. Это запросы внутри блока ВЫБРАТЬ, которые выполняются для каждой строки результата.

Посмотрим на пример:


ВЫБРАТЬ
    Задачи.Ссылка,
    Задачи.Наименование,
    (ВЫБРАТЬ ТОП 1 ДопСведения.Значение 
     ИЗ РегистрСведений.ДополнительныеСведения КАК ДопСведения 
     ГДЕ ДопСведения.Объект = Задачи.Ссылка) КАК ДопИнфо
ИЗ
    Задача.ЗадачаИсполнителя КАК Задачи

Почему это может быть эффективно? Платформа 1С оптимизирует такой запрос: подзапрос будет выполнен только для тех строк, которые реально отображаются на экране (например, 20-45 строк). Если бы мы использовали сложное соединение с временной таблицей, системе пришлось бы подготовить весь объем данных заранее.

Роль основной таблицы и инструкции РАЗРЕШИТЬ

Для корректной и быстрой работы динамического списка крайне важно правильно настроить его свойства в конфигураторе:

Основная таблица: Всегда указывайте основную таблицу (например, Справочник.Номенклатура). Это позволяет платформе использовать стандартные механизмы фильтрации и сортировки на уровне СУБД, а также корректно работать с правами доступа (RLS).
Инструкция РАЗРЕШИТЬ: Если в системе настроены ограничения прав доступа на уровне записей (RLS), отсутствие слова РАЗРЕШИТЬ может привести к тому, что система будет проверять права для всех записей таблицы, что крайне медленно. С этой инструкцией проверка прав будет ограничена только выбираемой порцией данных.

Механизм расширения и вычисляемые поля

Помните, что динамический список в 1С автоматически оптимизирует состав полей. Если в тексте запроса указано ВЫБРАТЬ *, но на форму выведены только два поля, платформа исключит лишние колонки из SQL-запроса. Однако, если вы пропишете сложные вычисления или обращения "через 5 точек" прямо в тексте запроса, эта оптимизация может не сработать.

Совет: Сложные условия и вычисления лучше выносить в "Вычисляемые поля" в настройках динамического списка (на закладке "Настройки компоновки данных"). Это позволит системе компоновки более гибко управлять производительностью.

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