В крупных информационных базах на платформе 1С:Предприятие 8.3, таких как 1С:ERP 2.4, пользователи часто сталкиваются с существенным замедлением работы при поиске в справочниках. Типичная ситуация: в справочнике «Номенклатура» около 100 000 записей, на форму выведено более 10 дополнительных реквизитов (тип «Строка»), и стандартный поиск по строке начинает работать крайне медленно. При этом поиск через расширенный отбор (ALT+F) по конкретному полю (например, Артикул) выполняется мгновенно. Рассмотрим причины такого поведения системы и разберем по шагам способы решения этой задачи.
Для начала проанализируем ситуацию с технической стороны. Когда пользователь начинает вводить текст в строке поиска динамического списка, платформа 1С по умолчанию пытается найти это вхождение во всех видимых колонках списка. Если на форму выведены дополнительные реквизиты, механизм запроса значительно усложняется.
В 1С:ERP дополнительные реквизиты хранятся в табличных частях (для справочника Номенклатура это ТЧ ДополнительныеРеквизиты). При выводе их в динамический список система выполняет «левое соединение» (LEFT JOIN) с этой таблицей для каждого выведенного реквизита. Если у нас выведено 10 дополнительных реквизитов, SQL-запрос превращается в тяжелую конструкцию с множеством соединений. Ситуация усугубляется тем, что поиск по строке генерирует условие LIKE '%Текст%', которое не позволяет SQL-серверу использовать индексы, заставляя его выполнять полное сканирование таблиц (Full Scan).
Самый эффективный способ ускорить «быстрый поиск» (когда пользователь просто набирает текст в списке) — это ограничить состав полей, по которым платформа будет искать совпадения. Мы можем принудительно указать системе, что искать нужно только по артикулу или наименованию, игнорируя тяжелые дополнительные реквизиты.
Рассмотрим, как это реализовать в модуле формы списка справочника Номенклатура. Нам необходимо изменить свойства динамического списка в процедуре ПриСозданииНаСервере:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Определим массив полей, по которым будет идти поиск при наборе текста
МассивПолейПоиска = Новый Массив;
МассивПолейПоиска.Добавить("Артикул");
МассивПолейПоиска.Добавить("Наименование");
// Устанавливаем ограничение для динамического списка (обычно называется Список)
Список.ПоляПоиска = МассивПолейПоиска;
КонецПроцедуры
После внесения этого изменения, когда пользователь начнет набирать текст, система не будет обращаться к значениям дополнительных реквизитов в условиях фильтрации, что сократит время выполнения SQL-запроса в разы.
Если пользователи привыкли искать исключительно по артикулу, целесообразно вынести поле отбора «Артикул» непосредственно в шапку формы. Это избавит их от необходимости нажимать лишние клавиши и обеспечит максимальную производительность. Выясним, как настроить такой механизм:
ОтборАртикул с типом Строка).ПриИзменении этого реквизита пропишите код установки отбора в динамическом списке.Пример кода для реализации быстрого отбора:
&НаКлиенте
Процедура ОтборАртикулПриИзменении(Элемент)
УстановитьОтборСписка(ОтборАртикул);
КонецПроцедуры
&НаСервере
Процедура УстановитьОтборСписка(ЗначениеАртикула)
// Удаляем старый отбор, если он был
ОбщегоНазначенияКлиентСервер.УдалитьЭлементыОтбора(Список.Отбор, "Артикул");
// Если значение заполнено, устанавливаем новый отбор
Если Не ПустаяСтрока(ЗначениеАртикула) Тогда
ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбора(Список.Отбор, "Артикул", ЗначениеАртикула, ВидСравненияКомпоновкиДанных.Содержит);
КонецЕсли;
КонецПроцедуры
Важный нюанс: использование ВидСравненияКомпоновкиДанных.НачинаетсяС вместо Содержит будет работать еще быстрее, так как SQL-сервер сможет задействовать индекс по полю Артикул.
Разберем более радикальный, но архитектурно правильный способ решения проблемы для высоконагруженных систем. Если дополнительные реквизиты используются постоянно, по ним строятся отчеты и выполняется поиск, то механизм ДополнительныеРеквизитыИСведения становится «узким местом» производительности.
Проанализируем трудозатраты на перенос данных. Для оптимизации следует добавить наиболее часто используемые строковые доп. реквизиты как полноценные реквизиты справочника Номенклатура. Это позволит:
Процесс перехода включает несколько этапов:
ПриЗаписи), чтобы поддерживать актуальность данных, если вы решите оставить доп. реквизиты для совместимости.Мало кто знает, что дополнительные реквизиты можно индексировать средствами самой платформы без изменения конфигурации. Проверим эту настройку:
Перейдите в раздел Администрирование — Общие настройки — Дополнительные реквизиты и сведения. Найдите нужный реквизит и проверьте, стоит ли флаг «Индексировать». Если этот флаг включен, система создает индекс в таблице дополнительных сведений, что ускоряет отборы, но, к сожалению, мало помогает при полнотекстовом поиске LIKE '%...%' во всех колонках сразу.
Если в базе включен полнотекстовый поиск, динамический список может использовать его для строки поиска. Выясним причины, почему это может не работать:
ОбновлениеИндексаППД работает корректно и без ошибок.АвтоматическоеИспользованиеПолнотекстовогоПоиска. Оно должно быть установлено в значение Использовать или Авто.При правильно настроенном ППД платформа не формирует сложные LIKE запросы, а обращается к индексу полнотекстового поиска, что значительно быстрее при больших объемах данных.
Мы проанализировали ситуацию и выяснили, что основной причиной тормозов в ERP 2.4 являются соединения с табличными частями дополнительных реквизитов при глобальном поиске по списку. Для оперативного решения проблемы рекомендуем:
Артикул и Наименование. Это самый дешевый и быстрый способ.ПриИзменении.Помните, что комфортная работа пользователя напрямую зависит от скорости отклика интерфейса, и в случае с ERP 2.4 настройка динамических списков является критически важной задачей администратора и разработчика.