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

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

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

Анализ причины: почему СУБД зависает при открытии формы

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

Рассмотрим, как устроен регистр накопления на уровне базы данных:

1. Кластерный индекс таблицы движений: физическая таблица движений регистра накопления по умолчанию упорядочена с помощью кластерного индекса с составом полей Период + Регистратор + НомерСтроки.
2. Отсутствие отдельного индекса: отдельный индекс исключительно по полю Регистратор в структуре регистра отсутствует (он является лишь вторым полем составного индекса).
3. Поведение динамического списка: динамический список запрашивает данные у СУБД порциями (страницами). Если сортировка в списке установлена по лидирующему полю индекса — по полю Период, сервер СУБД мгновенно считывает первые несколько десятков строк прямо из индекса (операция Index Seek или направленный Index Scan) и сразу возвращает их на клиент.
4. Сортировка по неиндексированному полю: если пользователь или разработчик задает сортировку по полю Регистратор, СУБД не может применить индекс для быстрой выборки первых N строк. В этом случае серверу приходится выполнять полное сканирование всей многомиллионной таблицы (Table Scan / полный Index Scan), выгружать все данные во временную память (tempdb) и производить тяжелую сортировку всего массива записей перед выдачей первой страницы.

Решение 1: Изменение порядка сортировки в форме списка

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

Разберем по шагам, как исправить порядок сортировки:

1. Откроем форму регистра или форму списка документов.
2. Перейдем в меню Еще — Настроить список....
3. На вкладке Сортировка удалим сортировку по полю Регистратор.
4. Установим сортировку по полю Период (по возрастанию или по убыванию).
5. Нажмем кнопку Завершить редактирование.

После применения этой настройки динамический список начинает считывать порции данных за доли секунды даже в таблицах с объемом более 20–30 млн записей.

Решение 2: Проверка настроек динамического списка в конфигураторе

Если форма списка разрабатывается или дорабатывается в конфигураторе, важно проконтролировать ключевые свойства динамического списка:

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

Решение 3: Оптимизация RLS и регламентное обслуживание СУБД

Если сортировка настроена правильно, но форма все равно открывается медленно, проанализируем сопутствующие факторы производительности:

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

Методологические рекомендации: расчет партий в прикладных решениях

Нередко пользователи открывают форму регистра накопления ПартииТоваровОрганизаций исключительно ради служебных действий (например, для интерактивного нажатия кнопки расчета или актуализации партий).

Рассмотрим, как правильно организовать работу с партионным учетом:

1. Использование регламентного закрытия месяца: интерактивный запуск расчета партий из формы регистра предназначен для отладки. В штатном режиме актуализация движений и расчет себестоимости должны выполняться через рабочее место Закрытие месяца (обработка Регламентные операции по закрытию месяца).
2. Настройка фонового расчета: для автоматического расчета себестоимости настраивается предопределенное регламентное задание, выполняющееся по расписанию в нерабочие часы или с заданной периодичностью.
3. Использование типовых отчетов: для анализа движений и остатков партий следует использовать специализированные отчеты (например, «Ведомость по партиям товаров»), а не интерактивный просмотр всей таблицы движений регистра.