← На главную

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

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

Причина явления: специфичный пользовательский отбор

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

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

Диагностика и шаг 1: Проверка и сброс пользовательских настроек

Рассмотрим первый и самый быстрый способ восстановления нормальной скорости работы формы — анализ и очистку настроек динамического списка.

1. Проверка установленных отборов в форме: Зайдем в форму списка номенклатуры под проблемным пользователем, откроем меню Еще > Настроить список... и перейдем на закладку Отбор. Проанализируем, какие реквизиты используются в условиях.
2. Поиск неэффективных условий: Обратим внимание на наличие отборов с видом сравнения Содержит, Не равно, Не в списке или условий по реквизитам соединенных таблиц (например, остатки, цены, штрихкоды). Такие фильтры делают невозможным использование индексов СУБД.
3. Сброс настроек формы: В окне настройки списка выполним команду Еще > Установить стандартные настройки. Если торможения прекратились, значит причиной действительно был неоптимальный отбор.
4. Полная очистка настроек пользователя: Если сброс через форму не помог или требуется очистить настройки административно, перейдем в раздел Администрирование > Настройки пользователей и прав > Персональные настройки пользователей > Очистка настроек и удалим сохраненные настройки формы списка номенклатуры для данного пользователя.

Технические причины медленной работы отборов на стороне СУБД

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

1. Отбор по неиндексированному полю: Если отбор установлен по реквизиту справочника, для которого в конфигураторе не включено свойство Индексировать (или Индексировать с доп. упорядочиванием), оптимизатор SQL-сервера выбирает план выполнения Table Scan или Index Scan вместо точечного поиска Index Seek.
2. Поиск по подстроке: Использование оператора LIKE '%строка%' блокирует применение стандартных индексов B-Tree, что приводит к перебору всех записей таблицы номенклатуры при любом изменении порядка сортировки.
3. Сложная структура запроса динамического списка: При наличии левых соединений с детальными таблицами (срезы последних цен, текущие остатки, дополнительное описание) наложение пользовательского отбора заставляет СУБД перечитывать массив данных всех связанных таблиц.
4. Разграничение доступа на уровне записей (RLS): Если для пользователя включены механизмы RLS, к текущему отбору пользователя скрыто добавляются подзапросы проверки прав, что кратно увеличивает нагрузку на сервер БД.

Рекомендации по предотвращению проблемы в конфигурации

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

1. Индексация реквизитов в Конфигураторе: Для полей номенклатуры, по которым пользователи часто выполняют отбор или сортировку (например, Артикул, Код, Наименование, ВидНоменклатуры), установим свойство Индексировать или Индексировать с доп. упорядочиванием.
2. Ограничение полей для произвольного отбора: В настройках элементов динамического списка или программно с помощью метода УстановитьОграниченияИспользованияВОтборе() запретим наложение отборов по вычисляемым, соединенным или сложным реквизитам.
3. Оптимизация настройки «Динамическое считывание данных»: В свойствах динамического списка проверим состояние флага Динамическое считывание данных. При его включении платформа запрашивает данные с сервера порциями по 45 записей, что ускоряет первичную отрисовку формы при больших объемах данных.
4. Регламентные работы СУБД: Убедимся, что на SQL-сервере регулярно выполняются операции обновления статистики (UPDATE STATISTICS), а также реиндексация и дефрагментация таблиц базы данных.