← На главную

При интерактивной работе с управляемыми формами в «1С:Предприятии 8.3» разработчики и пользователи сталкиваются с ситуацией, когда активация стандартного поиска (комбинация клавиш Ctrl + Alt + F или расширенный поиск) приводит к ощутимым задержкам интерфейса. Подвисания начинают проявляться при выполнении практически любых пользовательских действий: при переходе по строкам таблицы, выполнении контекстных команд и даже при вызове пустых клиент-серверных процедур. В типовых конфигурациях, таких как «1С:ERP Управление предприятием» и «1С:Зарплата и управление персоналом», задержка в списках вроде договоров контрагентов может составлять одну-две секунды, а в сложных самописных формах с объемными запросами доходить до пяти секунд и более.

Характерной особенностью проблемы является то, что при установке структурного отбора через диалог «Настроить список» подвисания не возникают. Пользователи при этом привыкли пользоваться именно встроенным поиском по сочетанию клавиш, из-за чего простое скрытие кнопки вызывает сопротивление со стороны бизнес-пользователей.

Разница в механизмах наложения условий: отбор против поиска

Главная техническая причина разницы в скорости работы кроется в том, какие именно условия накладываются платформой на результирующий SQL-запрос динамического списка к СУБД:

• Отбор через «Настроить список»: при фильтрации по конкретному полю (например, равенство ссылке, дате, числу или вхождение в список значений) платформа транслирует условие в строгое сопоставление. СУБД использует существующие B-Tree индексы таблицы, выполняя точечный поиск по индексу (Index Seek). Нагрузка на дисковую подсистему и процессор сервера остается минимальной.
• Поиск через «Найти» (Ctrl + Alt + F): по умолчанию стандартный поиск платформы предназначен для контекстного сопоставления строковых значений. Если выбран режим поиска по части строки, платформа генерирует предикат с маской вида ПОДОБНО '%Текст%' либо обращается к полнотекстовому поиску. Наличие знака процента в начале шаблона делает невозможным применение классических B-Tree индексов реляционной базы данных. СУБД вынуждена выполнять полное сканирование таблицы или индекса (Table Scan / Index Scan), считывая и проверяя каждую запись.

Почему задержки возникают при любых действиях на форме

Динамический список считывает данные порциями, достаточными для отображения на экране. Однако при выполнении серверных вызовов из формы (включая срабатывание обработчика ПриАктивизацииСтроки, нажатие кнопок командной панели или обновление формы) клиентское приложение синхронизирует состояние с сервером. В этот момент динамический список валидирует текущую позицию курсора и проверяет видимый диапазон строк.

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

План проверки и локализации проблемы

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

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

Варианты решений и оптимизации

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

1. Оптимизация обработчика смены строки

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

2. Использование поиска по началу строки

При поиске через «Найти» можно рекомендовать пользователям выбирать режим «по началу строки». В этом случае формируется условие ПОДОБНО 'Текст%'. Такое условие позволяет СУБД задействовать существующие строковые индексы по реквизиту (например, по наименованию или коду), исключая полное сканирование таблицы.

3. Проверка полнотекстового индекса

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

4. Упрощение схемы запроса динамического списка

Для сложных самописных списков следует проверить следующие параметры:

• Обязательно указать реквизит «Основная таблица» в свойствах динамического списка, чтобы платформа могла оптимизировать получение данных и применять стандартные механизмы отборов.
• Минимизировать соединения с другими таблицами в основном тексте запроса. По возможности выносить получение вторичных колонок в реквизиты основной таблицы или использовать определяемые поля без тяжелых соединений.

5. Отключение стандартного поиска в пользу быстрых отборов

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