Почему тормозит поиск в справочнике Номенклатура и как это исправить

Многие технические специалисты сталкиваются с ситуацией, когда стандартный поиск в динамическом списке начинает «подвисать» или работать крайне медленно. Особенно часто это проявляется в справочнике Номенклатура, где объем данных велик, а пользователи активно используют строку поиска. Рассмотрим детально, почему это происходит и как локализовать проблему, если она проявляется избирательно — только у одного или нескольких сотрудников.

Анализируем влияние пользовательских настроек

Если поиск тормозит только у одного пользователя, в то время как у администратора или коллег всё работает мгновенно, первоочередная причина кроется в пользовательских настройках формы. Рассмотрим механизм работы механизма «Изменить форму». Когда пользователь самостоятельно добавляет колонки в список, платформа динамически модифицирует SQL-запрос, который отправляется к серверу базы данных.

Проанализируем ситуацию, описанную в теме: пользователь добавил реквизит Входит в группу через команду «Изменить форму». На первый взгляд, это безобидное действие, но для платформы 1С это сигнал к использованию оператора В ИЕРАРХИИ в SQL-запросе. Разберем, почему это критично:

1. При вводе текста в строку поиска система пытается найти совпадение по всем видимым полям списка.
2. Если в списке присутствует поле, завязанное на иерархию, SQL-сервер вынужден выполнять сложные рекурсивные вычисления или тяжелые подзапросы для каждой строки, чтобы определить соответствие условию поиска.
3. В сочетании с оператором LIKE (ПОДОБНО) это создает колоссальную нагрузку, приводя к «зависанию» интерфейса и отмене фонового задания по таймауту.

Проблема обращения к реквизитам «через точку»

Другой важный аспект, который мы должны рассмотреть — это добавление полей через навигационные свойства (через точку от основной ссылки). Например, если в список номенклатуры добавлено поле Номенклатура.Производитель.Страна.

Выясним, что происходит на уровне СУБД: каждое такое поле добавляет к основному запросу динамического списка оператор LEFT JOIN. Если таких полей несколько, и по ним активирован поиск, SQL-запрос превращается в «монстра» с десятком присоединений. Поиск по подстроке в такой структуре не может использовать индексы эффективно, что приводит к полному сканированию таблиц (Table Scan).

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

Взаимодействие с Полнотекстовым поиском (ППД)

Платформа 1С:Предприятие, начиная с версии 8.3.15, существенно изменила логику работы глобального поиска в списках. Проанализируем два режима:

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

2. Полнотекстовый поиск выключен. Система переходит на классический SQL-запрос с использованием LIKE '%Текст%'. Такой поиск находит вхождения в середине слова (например, «пласт» в слове «сплав»), но он работает крайне медленно на больших таблицах, так как индексы по строковым полям не поддерживают поиск с диким символом (wildcard) в начале строки.

Посмотрим на пример того, как платформа может формировать условие (условно):

ВЫБРАТЬ ПЕРВЫЕ 100
    СправочникНоменклатура.Наименование
ИЗ
    Справочник.Номенклатура КАК СправочникНоменклатура
ГДЕ
    СправочникНоменклатура.Наименование ПОДОБНО "%пакет%"
    ИЛИ СправочникНоменклатура.Артикул ПОДОБНО "%пакет%"

Пошаговый алгоритм решения проблемы

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

1. Очистка пользовательских настроек. Не путайте это с кэшем на диске. Нужно зайти в раздел «Администрирование» — «Настройки пользователей и прав» — «Очистка настроек». Выберите проблемного пользователя и удалите настройки для формы списка номенклатуры. Это вернет форму к «заводскому» виду и уберет тяжелые поля, добавленные через «Изменить форму».
2. Сброс кэша метаданных. Удалите папку с кэшем пользователя в каталогах %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8. Это исключит влияние битых временных файлов.
3. Актуализация индекса ППД. Если используется полнотекстовый поиск, запустите регламентное задание ОбновлениеИндексаППД и СлияниеИндексаППД. Также полезно очистить и полностью перезаполнить индекс через управление полнотекстовым поиском.
4. Обновление статистики SQL. Если база работает на MS SQL Server или PostgreSQL, выполните обновление статистики (Update Statistics). Это поможет оптимизатору СУБД строить более эффективные планы запросов.
5. Проверка RLS. Если у пользователя ограничены права (например, по группам доступа), платформа добавляет к каждому поисковому запросу сложные условия проверки прав. Попробуйте временно дать пользователю полные права для теста: если тормоза исчезнут — проблему нужно решать оптимизацией шаблонов RLS.

Особенности поиска «При вводе» в документах

Важно различать поиск в самой форме справочника и поиск при вводе в поле документа. Как мы выяснили из обсуждения, тормоза часто возникают именно при подборе в документе. В этом случае срабатывает обработчик ОбработкаПолученияДанныхВыбора. В типовых конфигурациях (БП 3.0, УТ 11) в этом месте часто прописаны дополнительные проверки на остатки или цены. Если в базе много помеченных на удаление объектов или дублей, это также замедляет процесс.

Для оптимизации этого процесса можно программно ограничить количество полей, по которым ведется поиск:

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    // Ограничиваем список полей для поиска, чтобы ускорить работу
    Список.ПараметрыПоиска.ПоляПоиска = "Наименование,Артикул";
КонецПроцедуры

Подводя итог, можно сказать, что в 90% случаев проблема «тормозов у одного юзера» решается удалением его персональных настроек формы. Приучайте пользователей не загромождать динамические списки лишними полями, особенно иерархическими реквизитами и данными из связанных справочников, так как это напрямую влияет на отзывчивость системы.