Многие разработчики сталкиваются с ситуацией, когда обычный динамический список в управляемой форме работает мгновенно под правами администратора, но вызывает значительные задержки (до нескольких минут) у рядовых пользователей. Ситуация становится еще более загадочной, когда в запросе динамического списка отсутствует ключевое слово РАЗРЕШЕННЫЕ, но пользователь все равно видит только ограниченный набор данных. В этой статье мы подробно разберем, как «под капотом» работает механизм Record Level Security (RLS), почему возникают тормоза и как их диагностировать.
Прежде всего, разберем главный вопрос: как применяются ограничения, если в коде запроса не написано РАЗРЕШЕННЫЕ? Проанализируем поведение платформы 1С:Предприятие. Для динамических списков режим выбора только разрешенных записей включен автоматически на уровне ядра платформы. Это сделано для обеспечения стабильности интерфейса: если бы платформа пыталась прочитать объект, на который у пользователя нет прав, возникла бы ошибка «Объект не обнаружен», что недопустимо при пролистывании списка.
Когда запрос динамического списка отправляется на СУБД (SQL Server или PostgreSQL), платформа выполняет трансформацию исходного текста. Она анализирует роли пользователя и шаблоны RLS, заданные в метаданных для конкретного объекта (например, документа РеализацияТоваровУслуг). В итоговый SQL-запрос добавляется секция WHERE, содержащая сложные условия, подзапросы или соединения с таблицами прав. Таким образом, отсутствие слова РАЗРЕШЕННЫЕ в конструкторе динамического списка не означает отсутствие фильтрации — платформа просто делает эту работу за вас незаметно.
Рассмотрим ситуацию, когда задержка возникает на этапе КонецПроцедуры в обработчике ПриСозданииНаСервере. На первый взгляд кажется, что выполнение кода завершено, но форма не открывается. Проанализируем последовательность событий:
ПриСозданииНаСервере.ПриЗагрузкеПользовательскихНастроекНаСервере).Задержка, которую вы видите «в конце процедуры», на самом деле является временем ожидания ответа от СУБД. Платформа трансформировала ваш простой запрос в огромную конструкцию с RLS-фильтрами, и СУБД тратит время на построение плана выполнения и выборку данных.
Если ваша конфигурация основана на Библиотеке стандартных подсистем (БСП), важно выяснить, какой режим ограничения доступа используется. Рассмотрим два варианта:
1. Стандартный режим. Ограничения накладываются через классические шаблоны RLS прямо в запросе. Это часто приводит к созданию неоптимальных SQL-запросов, особенно если в шаблонах используются обращения через точку (например, ГДЕ Склад.Организация = &Параметр). Такие обращения превращаются в LEFT JOIN, что при большом объеме данных катастрофически замедляет работу.
2. Производительный режим. В этом режиме БСП использует заранее рассчитанные таблицы — регистры сведений семейства КлючиДоступа.... Вместо того чтобы вычислять права «на лету», запрос динамического списка просто соединяется с таблицей ключей доступа для текущего пользователя. Это работает в разы быстрее, но требует актуальности данных в регистрах. Проверьте состояние регламентного задания «Заполнение данных для ограничения доступа».
Чтобы понять причину тормозов, мы должны увидеть «истинное лицо» запроса. Выполним следующие шаги:
Возьмем текст запроса из динамического списка и запустим его в консоли запросов под пользователем с ограниченными правами. Если вы используете консоль, поддерживающую РАЗРЕШЕННЫЕ, вы сразу увидите разницу в скорости. Рассмотрим пример:
// Обычный запрос под администратором выполняется 0.1 сек
ВЫБРАТЬ
Реализация.Ссылка,
Реализация.Номер
ИЗ
Документ.РеализацияТоваровУслуг КАК Реализация
// Тот же запрос под пользователем с RLS превращается в SQL-монстра
Для детального анализа рекомендуется использовать Технологический журнал. Настройте сбор событий DBMSSQL (или DBPOSTGRS) с отбором по длительности выполнения. В логах вы увидите реальный SQL-текст. Обратите внимание на наличие в нем условий OR и соединений с временными таблицами. Если в плане запроса СУБД вы видите Index Scan по неиндексированным полям или Full Table Scan, причина тормозов найдена.
Проанализируем основные способы ускорения работы:
Если ваш RLS настроен по полям Организация, Подразделение или Склад, эти реквизиты обязательно должны быть индексированы в метаданных. Без индексов СУБД будет вынуждена перебирать все документы в базе, чтобы проверить, разрешен ли конкретный документ пользователю. Установите свойство «Индексировать» или «Индексировать с доп. упорядочиванием» для этих реквизитов.
Разберем типичную ошибку в шаблоне RLS:
#Параметр(1) ГДЕ Ссылка.Организация = &Организация
Такое условие заставляет платформу делать лишнее соединение. Лучше использовать прямой реквизит объекта, если это возможно.
Динамический список запрашивает данные порциями. Однако, если из миллиона записей пользователю разрешено всего 100, СУБД может просмотреть 900 000 запрещенных строк, прежде чем найдет первые 45 разрешенных для показа на экране. В таких случаях стоит рассмотреть возможность наложения жесткого отбора в настройках списка (например, по периоду или текущему подразделению), чтобы сузить область поиска для RLS.
Если конфигурация позволяет, перейдите на «Производительный» режим работы доступа. Это существенно упростит SQL-запросы, так как сложные условия заменятся на простое соединение с таблицей разрешенных ключей.
Подводя итог, можно сказать: тормоза в динамическом списке при RLS — это почти всегда следствие либо отсутствия индексов, либо слишком сложной структуры шаблонов ограничений, которые превращают простой SELECT в тяжелую аналитическую задачу для СУБД. Анализируйте итоговые SQL-запросы, и вы всегда найдете узкое место.