Зависание динамического списка — одна из самых коварных проблем в разработке на платформе 1С:Предприятие 8.3. Ситуация часто осложняется тем, что под полными правами всё «летает», а у рядовых пользователей интерфейс замирает на минуты. В этой статье мы подробно разберем, почему простой, на первый взгляд, запрос может поставить систему «на колени», и как оптимизировать работу журналов документов.
Проанализируем исходный запрос автора темы. В секции ГДЕ мы видим следующее условие:
ГДЕ
ЕСТЬNULL(ЖурналДокументовСкладскиеДокументы.Ссылка.ВидОтгрузки, ЗНАЧЕНИЕ(Перечисление.ВидыОтгрузкиТоваров.Склад)) = ЗНАЧЕНИЕ(Перечисление.ВидыОтгрузкиТоваров.Склад)
Разберем, что здесь происходит с точки зрения системы. Поле Ссылка в журнале документов является ссылкой на разные типы документов (составной тип данных). Когда мы пишем Ссылка.ВидОтгрузки, платформа 1С вынуждена выполнить неявное соединение (LEFT JOIN) основной таблицы журнала со всеми таблицами документов, входящих в этот журнал, чтобы найти реквизит ВидОтгрузки.
Если в журнал входит 10 типов документов, СУБД придется выполнить 10 соединений. В динамическом списке, который должен работать быстро и порционно, такие «прыжки через точку» вызывают колоссальную нагрузку на дисковую подсистему и процессор сервера БД. Это и есть первая причина «замирания» списка.
Решение: Как правильно советуют в обсуждении, необходимо добавить реквизит ВидОтгрузки непосредственно в состав колонок самого Журнала документов на вкладке «Данные». После этого к нему можно будет обращаться напрямую: ЖурналДокументовСкладскиеДокументы.ВидОтгрузки, исключив обращение через Ссылка.
Вторая критическая ошибка в запросе — использование функции ЕСТЬNULL в секции фильтрации. В мире баз данных существует понятие Sargable (Search Argumentable) запросов. Это запросы, которые могут эффективно использовать индексы.
Когда вы оборачиваете поле в функцию (например, ЕСТЬNULL, НАЧАЛОПЕРИОДА, ПОДСТРОКА) внутри условия ГДЕ, SQL-сервер не может использовать индекс по этому полю. Ему приходится выполнять Index Scan или Table Scan — то есть перебирать абсолютно все записи в таблице, чтобы вычислить результат функции для каждой строки, и только потом сравнивать его со значением. Если в журнале сотни тысяч записей, это гарантированное зависание.
Рекомендация по оптимизации: Избегайте функций над полями таблиц в условиях. Если вам нужно обрабатывать NULL, лучше заранее обеспечить заполнение реквизитов значениями по умолчанию или перестроить логику отбора так, чтобы она работала с «чистыми» индексированными полями.
Рассмотрим ситуацию: почему у администратора всё работает быстро, а у пользователя — нет? Ответ кроется в механизме RLS. Когда пользователь с ограниченными правами открывает список, платформа модифицирует ваш запрос «на лету», добавляя в него условия из ролей.
Если в ролях прописаны сложные ограничения (например, проверка прав по подразделению или складу через несколько соединений), то итоговый SQL-запрос превращается в огромного «монстра». В сочетании с вашим исходным неоптимальным запросом (с точками и ЕСТЬNULL), оптимизатор SQL-сервера может выбрать крайне неэффективный план выполнения.
Для диагностики этого состояния полезно временно дать пользователю полные права. Если проблема исчезла — значит, нужно пересматривать шаблоны RLS в конфигурации, упрощая их и избавляясь от обращений через точку внутри шаблонов ролей.
Почему иногда помогает пересоздание пользователя? При открытии формы 1С считывает настройки из системного хранилища (таблица SystemSettingsStorage). В этих настройках хранится сортировка.
Представим ситуацию: пользователь случайно нажал на заголовок колонки, которая не проиндексирована в базе данных (или является вычисляемой через точку). Динамический список при каждом открытии будет пытаться отсортировать весь объем данных по этой неэффективной колонке. Для СУБД это означает создание временных таблиц и огромные затраты времени.
Вместо удаления пользователя, мы можем выполнить очистку настроек формы:
После этого форма откроется с сортировкой по умолчанию (обычно по дате), которая работает быстро благодаря стандартным индексам.
Разберем по шагам, что нужно сделать программисту для исправления ситуации:
ЖурналДокументов.СкладскиеДокументы. На вкладке «Данные» добавьте новый реквизит (например, ВидОтгрузки). В списке документов, входящих в журнал, укажите соответствие этого реквизита полям документов. Это позволит платформе хранить значение в основной таблице журнала.
ВЫБРАТЬ
Журнал.Ссылка,
Журнал.Дата КАК Период,
Журнал.Номер,
Журнал.ВидОтгрузки // Теперь это поле самого журнала
ИЗ
ЖурналДокументов.СкладскиеДокументы КАК Журнал
ГДЕ
Журнал.ВидОтгрузки = ЗНАЧЕНИЕ(Перечисление.ВидыОтгрузкиТоваров.Склад)
РАЗРЕШЕННЫЕ в текст запроса, чтобы платформа могла оптимизировать выборку на уровне СУБД.ВидОтгрузки используется постоянно, убедитесь, что это поле проиндексировано. В свойствах реквизита журнала установите «Индексировать» или «Индексировать с доп. упорядочиванием».Выполнив эти шаги, мы превращаем «тяжелый» запрос с множеством соединений в легкую и быструю выборку из одной таблицы с использованием индексов. Это гарантирует стабильную работу журнала даже при миллионах записей в базе данных.