Зачем используется конструкция ВЫБРАТЬ 1 КАК ПолеОтбора в ограничениях RLS

При изучении типовых шаблонов ограничения доступа на уровне записей (RLS) в конфигурациях на платформе 1С:Предприятие (например, УТП, УПП 1.3, КА 1.1, УТ 10.3) часто встречается специфическая конструкция с вложенным запросом (ВЫБРАТЬ 1 КАК ПолеОтбора) КАК Оптмизация. Разберем подробно, какую роль выполняет данный фрагмент кода, как он влияет на формирование плана запроса в СУБД и какие современные альтернативы существуют.

Анализ структуры запроса ограничения прав

Рассмотрим типовой пример подзапроса ограничения прав доступа к данным:

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

Проанализируем работу данного фрагмента по шагам:

1. Эмуляция оператора проверки существования: В языке запросов 1С отсутствует прямая конструкция EXISTS (...). Для проверки наличия хотя бы одной разрешающей записи используется условие вида ГДЕ 1 В (ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ ...). Если в регистре прав есть подходящая строка, подзапрос возвращает одну строку с единицей, условие становится истинным, и доступ к объекту разрешается. Если разрешающих записей нет, результат подзапроса пуст, и доступ блокируется.
2. Роль псевдотаблицы Оптмизация: Подзапрос (ВЫБРАТЬ 1 КАК ПолеОтбора) генерирует виртуальную таблицу, состоящую ровно из одной строки и одного поля (аналог системной таблицы DUAL в реляционных СУБД).
3. Формирование плана выполнения в СУБД: Исторически в версиях платформы 1С 8.0–8.2 прямое обращение к физической таблице регистра прав через секцию ГДЕ при трансляции в SQL не всегда позволяло оптимизатору СУБД (например, MS SQL Server) эффективно применить поиск по индексу. Соединение однострочной таблицы через конструкцию ВНУТРЕННЕЕ СОЕДИНЕНИЕ ... ПО принудительно направляло оптимизатор на выполнение операции точечного поиска по индексам измерений (Index Seek), предотвращая полное сканирование таблицы регистра (Table Scan) или неэффективные алгоритмы соединения.

Особенности и узкие места классического RLS

Несмотря на применение оптимизирующих конструкций, классический RLS на подзапросах обладает рядом существенных ограничений:

1. Нагрузка при масштабировании: Проверка прав выполняется динамически для каждой строки выборки. При формировании объемных отчетов или динамических списков на миллионы записей многократный расчет подзапросов к регистрам приводит к деградации производительности.
2. Сложности с составными типами данных: Если реквизит объекта доступа имеет составной тип данных, оптимизатор СУБД может потерять возможность эффективного использования индекса, что нивелирует пользу от вложенной псевдотаблицы.

Современные подходы к оптимизации ограничений доступа

Выясним, какие механизмы применяются в современных конфигурациях для замены устаревших шаблонов с подзапросами:

1. Использование производительного RLS на ключах доступа: В современных версиях Библиотеки стандартных подсистем (БСП) расчет прав выполняется заранее при записи объектов или регламентными фоновыми заданиями. Результаты сохраняются в регистрах КлючиДоступаКОбъектам и КлючиДоступаКРегистрам. В этом случае RLS сводится к простому и быстрому соединению по числовому идентификатору ключа.
2. Фильтрация через параметры сеанса: Фиксированные списки разрешенных значений (например, доступные текущему пользователю организации или подразделения) загружаются в параметры сеанса в виде массивов. Проверка сводится к прямому сравнению поля объекта со списком из параметра сеанса без обращения к регистрам в подзапросах.
3. Привилегированный режим: В фоновых заданиях, обработках группового перепроведения и процедурах формирования аналитических отчетов без ограничения прав следует программно отключать расчет RLS с помощью метода УстановитьПривилегированныйРежим(Истина) или выносить логику в привилегированные общие модули.