В современных конфигурациях 1С, таких как Управление торговлей 11.5 или ERP 2.5, разработчики часто сталкиваются с ситуацией, когда один и тот же запрос выполняется мгновенно под полными правами и критически медленно под обычным пользователем. Проанализируем типичную ситуацию: запрос к виртуальной таблице остатков и оборотов, который занимает 0.9 секунды у администратора, превращается в 9–12 секунд ожидания для менеджера. Разберем по шагам, почему это происходит и как оптимизировать систему, используя профессиональный замер производительности контура 1С и поиск узких мест.
Первое, на что стоит обратить внимание — это используемый режим Ограничения доступа на уровне записей (RLS). В старых версиях БСП (Библиотеки стандартных подсистем) использовался классический механизм, который при каждом запросе динамически добавлял в текст SQL-запроса сложные вложенные подзапросы и соединения для проверки прав. Это создавало огромную нагрузку на СУБД. При настройке прав полезно выполнить оценку групп доступа пользователей, их профилей и их активных ролей (поможет анализ и сравнение прав доступа пользователей 1С), чтобы исключить избыточность условий.
Выясним, как это работает. При использовании ключевого слова РАЗРЕШЕННЫЕ платформа анализирует настройки в конфигураторе. Если там прописано условие типа #ПоЗначениямРасширенный, система будет «джойнить» таблицы прав к основному запросу. Если данных много (например, более 500 000 записей), SQL-сервер может построить неоптимальный план выполнения. Если прав слишком много, может потребоваться объединение профилей групп доступа для упрощения структуры ограничений.
Решение: Переход на Производительный режим RLS (также известный как универсальный механизм). В этом режиме права доступа рассчитываются заранее и хранятся в специальных справочниках и регистрах ключей доступа. SQL-запросу остается только соединиться с готовой таблицей ключей, что на порядок быстрее.
Для включения этого режима в УТ 11 выполним следующие действия:
Проанализируем сам текст запроса. Использование виртуальной таблицы ОстаткиИОбороты с периодичностью Регистратор — это одна из самых тяжелых операций для системы прав доступа. Рассмотрим пример запроса из темы:
ВЫБРАТЬ Разрешенные
Сумма(1) как тест
ИЗ
РегистрНакопления.РасчетыСКлиентами.ОстаткиИОбороты(, , Регистратор, , ОбъектРасчетов = &ОбъектРасчетов) КАК РасчетыОстаткиИОбороты
ГДЕ
РасчетыОстаткиИОбороты.АналитикаУчетаПоПартнерам.Организация = &Организация
Здесь допущена классическая ошибка: условие по организации вынесено в секцию ГДЕ. Это заставляет систему сначала получить данные из виртуальной таблицы (со всеми соединениями RLS), а потом фильтровать их. Правильнее перенести все фильтры в параметры виртуальной таблицы. В сложных случаях помогает проверка запросов на лишнюю выборку и разыменование полей составного типа, что позволяет выявить скрытые проблемы в тексте запроса.
Исправим запрос для повышения производительности:
ВЫБРАТЬ Разрешенные
Сумма(1) как тест
ИЗ
РегистрНакопления.РасчетыСКлиентами.ОстаткиИОбороты(
&НачалоПериода,
&КонецПериода,
Регистратор, ,
ОбъектРасчетов = &ОбъектРасчетов
И АналитикаУчетаПоПартнерам.Организация = &Организация
) КАК РасчетыОстаткиИОбороты
Если бизнес-логика позволяет, мы можем временно отключить проверку прав для конкретного тяжелого участка кода. Рассмотрим методику, когда данные сначала выбираются без ограничений в привилегированном модуле, а затем фильтруются программно. Для реализации этого в отчетах можно использовать готовые привилегированные отчеты, которые позволяют настроить выполнение запросов без наложения прав пользователя.
Посмотрим на пример реализации такого подхода в коде:
УстановитьПривилегированныйРежим(Истина);
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Расчеты.Ссылка КАК Ссылка
|ПОМЕСТИТЬ ВтДанные
|ИЗ
| РегистрНакопления.РасчетыСКлиентами КАК Расчеты
|ГДЕ
| Расчеты.ОбъектРасчетов = &ОбъектРасчетов";
Запрос.УстановитьПараметр("ОбъектРасчетов", ОбъектРасчетов);
Запрос.Выполнить();
УстановитьПривилегированныйРежим(Ложь);
// Далее работаем с ВтДанные, где уже накладываются права только на финальный результат
Важно: Этот метод следует использовать осторожно, только если вы уверены, что пользователь не получит доступ к конфиденциальным данным. Для контроля текущих настроек пригодится инструмент управление правами доступа и просмотр прав на объекты.
Часто пользователь жалуется на «тормоза при проведении», хотя на самом деле документ проводится быстро, а зависание происходит в момент обновления формы списка после закрытия документа. Проанализируем ситуацию: в динамическом списке включен RLS, и система пытается пересчитать видимые записи.
Разберем основные факторы замедления динамических списков:
Дата или Номер.SELECT COUNT(*). Рекомендуем установить значение «Не рассчитывать».Основная таблица. Это позволяет платформе использовать более эффективные механизмы ограничения доступа.Если после перехода на производительный RLS и оптимизации запросов скорость проведения документов все еще остается низкой (например, 20–30 секунд на один документ), необходимо проанализировать работу серверного оборудования. При проведении документа 1С активно пишет данные в регистры и одновременно обновляет таблицы ключей доступа (в новом RLS).
Проанализируем важные параметры СУБД:
TempDB и основные таблицы при обновлении RLS-ключей создают пиковую нагрузку. Если используются медленные диски на виртуальном сервере, это станет «бутылочным горлышком».Max Degree of Parallelism = 1. Это предотвращает ситуацию, когда один сложный запрос с RLS захватывает все ядра процессора, замедляя работу остальных пользователей.АналитикаУчетаПоПартнерам и КлючиДоступа. При высокой фрагментации даже производительный RLS начнет давать сбои.Таким образом, комплексный подход — переход на универсальный механизм RLS, перенос фильтров в параметры виртуальных таблиц и оптимизация динамических списков — позволяет сократить время выполнения запросов в десятки раз, обеспечивая комфортную работу пользователей даже в крупных базах данных.