← На главную

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

1. Анализ и оптимизация динамического списка управляемой формы

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

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

2. Оптимизация обработчиков формы и условного оформления

Выясним причину задержек при отрисовке строк. Нередко падение скорости связано с неоптимальным кодом в событиях формы:

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

   
   &НаСервере
   Процедура СписокПриПолученииДанныхНаСервере(Элемент, ОформленияСтрок)
       МассивСсылок = Новый Массив;
       Для Каждого СтрокаОформления Из ОформленияСтрок Цикл
           МассивСсылок.Добавить(СтрокаОформления.ДанныеСтроки.Ссылка);
       КонецЦикла;
       
       Запрос = Новый Запрос;
       Запрос.Текст = 
           "ВЫБРАТЬ
           |    Цены.Номенклатура КАК Ссылка,
           |    Цены.Цена КАК Цена
           |ИЗ
           |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, Номенклатура В (&МассивСсылок)) КАК Цены";
       Запрос.УстановитьПараметр("Период", ТекущаяДатаСеанса());
       Запрос.УстановитьПараметр("МассивСсылок", МассивСсылок);
       
       Выборка = Запрос.Выполнить().Выбрать();
       // Заполняем полученные данные в строки оформления
   КонецПроцедуры
   

2. Упрощение условного оформления: Избыточные правила условного оформления на уровне всей таблицы списка (особенно по сложным условиям с обращениями через точку) сильно замедляют отрисовку строк на клиенте. Оставим только критически важные правила.

3. Настройка режима отображения и иерархии

Для справочников сверхбольшого объема структура отображения имеет ключевое значение:

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

4. Организация быстрого поиска и фильтрации

Стандартный поиск по части строки (условие ПОДОБНО "%значение%") выполняет полное сканирование таблицы из 1 000 000 строк, что при многопользовательской работе парализует систему. Разберем альтернативные варианты:

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

5. Архитектура базы: файловый режим против клиент-серверного

Проанализируем влияние файлового режима работы при базе с 1 000 000 позиций:

1. Блокировки таблиц: В файловой базе (формат .1CD) при записи любого элемента или проведении документа блокируется вся таблица справочника целиком. Если один пользователь редактирует номенклатуру или проводит документ реализации, остальные пользователи в этот момент сталкиваются с зависанием формы списка.
2. Лимиты файлового формата: Внутренние таблицы файла .1CD имеют платформенные ограничения по размеру (по умолчанию до 4 ГБ на таблицу). Объемный каталог номенклатуры с историей цен, штрихкодами и табличными частями быстро приближается к этому пределу.
3. Перевод на СУБД (клиент-сервер): Перевод базы на SQL-сервер (PostgreSQL, MS SQL Server) снимает проблему глобальных файловых блокировок благодаря построчным блокировкам. Для небольших рабочих групп (до 5 пользователей) можно рассмотреть лицензию «1С:Предприятие 8.3. Сервер МИНИ».
4. Оптимизация файловой базы (если переход на SQL отложен): Если база временно остается файловой, необходимо разместить её на высокоскоростном SSD/NVMe диске, настроить исключения антивируса для каталога с базой и файлов платформы, а также регулярно выполнять процедуру «Тестирование и исправление» (реиндексацию и реструктуризацию таблиц).