Почему отчет в 1С формируется медленно под ограниченными ролями и как это исправить?

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

В чем главная причина падения производительности?

Основным виновником многократного замедления выборки данных является механизм RLS (Row-Level Security) — ограничение доступа на уровне записей и полей базы данных. Когда у пользователя включены полные права или отключена проверка прав на уровне записей, платформа отправляет в СУБД (MS SQL Server, PostgreSQL и др.) прямой и лаконичный SQL-запрос. Но как только отчет формирует пользователь с ограниченными правами, поведение платформы кардинально меняется.

Проанализируем технические причины, приводящие к падению производительности при включенном RLS:

1. Модификация исходного запроса платформой: Платформа 1С динамически переписывает запрос отчета, оборачивая обращения к таблицам в сложные подзапросы с множественными конструкциями WHERE, EXISTS и LEFT JOIN для проверки условий доступа по каждой таблице.
2. Объединение множества ролей через «ИЛИ»: Если пользователю назначено 10–15 различных ролей, условия ограничения доступа по каждой из них накладываются по логическому правилу ИЛИ. Это приводит к разрастанию текста результирующего SQL-запроса до огромных размеров и порождает многократные проверки одних и тех же таблиц.
3. Неоптимальные планы выполнения СУБД: Из-за нагромождения условий OR и вложенных соединений оптимизатор СУБД теряет возможность точно оценить кардинальность данных и выбирает неэффективные алгоритмы соединения таблиц (например, сканирование всей таблицы Table Scan вместо индексного поиска или медленные вложенные циклы Nested Loops).
4. Отсутствие индексов по полям ограничений: Если реквизиты, участвующие в шаблонах RLS (например, Организация, Подразделение, ГруппаДоступа), не проиндексированы в целевых справочниках и документах, СУБД сканирует всю таблицу целиком при каждой проверке прав.
5. Тяжелые условия в старых шаблонах RLS: Использование обращений к срезам последних или виртуальным таблицам внутри шаблонов ограничений приводит к тому, что подзапрос проверки прав выполняется для каждой возвращаемой строки отчета.

Способ 1. Использование привилегированного режима

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

Рассмотрим пример включения привилегированного режима в коде формирования отчета:

УстановитьПривилегированныйРежим(Истина);

// Формирование результата отчета через компоновщик или прямой запрос
ЭтотОбъект.СкомпоноватьРезультат(ДокументРезультат);

УстановитьПривилегированныйРежим(Ложь);

Также можно вынести процедуры выборки данных в общий модуль с установленным признаком Привилегированный и вызывать их оттуда на стороне сервера.

Способ 2. Переход на производительный режим RLS (БСП)

В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) реализован производительный режим ограничения прав. В отличие от классического RLS, где условия рассчитываются «на лету» в момент каждого запроса, производительный режим вычисляет права заранее в фоновом режиме.

Разберем, как устроен этот механизм:

1. Система формирует числовые идентификаторы прав и сохраняет их в регистрах сведений КлючиДоступаКОбъектам и КлючиДоступаПользователей.
2. При построении запросов платформа соединяется только с компактными таблицами ключей доступа по кластерным индексам, исключая громоздкие подзапросы.
3. Это позволяет ускорить построение отчетов под ограниченными правами практически до скорости работы под полными правами.

Способ 3. Аудит и оптимизация назначенных пользователю ролей

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

Выполним следующие действия по шагам:

1. Откроем список назначенных пользователю ролей и профилей групп доступа.
2. Исключим дублирующие роли, содержащие разные варианты RLS для одних и тех же объектов метаданных.
3. Объединим схожие роли в одну комплексную роль с единым прозрачным условием ограничения, чтобы избежать склейки условий через ИЛИ.

Способ 4. Проверка и добавление индексов

Проанализируем текст условий в шаблонах RLS для объектов, к которым обращается отчет. Убедимся, что все поля, по которым выполняется сопоставление (например, Организация, Партнер, Склад), имеют свойство Индексировать или ИндексироватьСДопУпорядочиванием.

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

Способ 5. Программная фильтрация вместо RLS в отчетах

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

Это позволяет получить гарантированно быстрый план запроса от СУБД с сохранением корректного ограничения видимости данных для пользователя.