Проблема низкой производительности динамических списков в крупных конфигурациях, таких как 1С:Комплексная автоматизация 2.5 или 1С:ERP, является одной из самых сложных задач для технического специалиста. Особенно остро она проявляется при использовании глобального поля «Поиск» в шапке списка. Пользователи сталкиваются с тем, что ввод одного слова приводит к зависанию системы на время от нескольких секунд до десятков минут. В данной статье мы подробно разберем, почему это происходит, и рассмотрим пошаговый алгоритм решения этой проблемы.
Для начала проанализируем, что происходит «под капотом» платформы 1С, когда пользователь вводит текст в поле поиска. В отличие от конкретного отбора по колонке, глобальный поиск не знает, в каком именно поле находится искомое значение. В результате платформа формирует SQL-запрос, в котором условие WHERE содержит оператор LIKE '%Текст%' для каждого текстового поля, включенного в состав динамического списка.
С точки зрения СУБД (например, MS SQL Server), поиск по строке, начинающийся с символа процента, делает невозможным использование классических B-Tree индексов. Система вынуждена выполнять полное сканирование всей таблицы (Table Scan или Index Scan). Если в вашем журнале документов миллионы записей, такой запрос гарантированно будет медленным. Ситуация усугубляется, если в список выведены поля неограниченной длины (например, «Комментарий»), поиск по которым требует еще больше ресурсов процессора и дисковой подсистемы.
Рассмотрим ситуацию с правами доступа. В современных конфигурациях 1С активно используется механизм RLS (Row Level Security). В режиме «Производительного RLS», который включен в КА 2.5 по умолчанию, платформа добавляет к основному запросу динамического списка временные таблицы с правами доступа текущего пользователя.
Проанализируем проблему: когда тяжелый поиск через LIKE накладывается на сложные условия RLS, количество логических чтений в SQL-сервере возрастает в геометрической прогрессии. Условия ограничения прав должны провериться для каждой строки, прошедшей фильтр по поиску. Если пользователь включен в большое количество групп доступа, запрос превращается в гигантскую конструкцию, которую оптимизатор SQL-сервера не может эффективно обработать. Именно поэтому проблема часто проявляется избирательно: у администратора всё работает быстро, а у рядового менеджера с ограниченными правами система «умирает».
Первое, что мы должны сделать — это минимизировать количество данных, по которым идет поиск. Часто в динамические списки (особенно в журналах документов) выводится избыточная информация. Рассмотрим основные рекомендации:
УстановитьОграниченияИспользованияВОтборе.Пример программного ограничения состава полей для поиска:
// В процедуре ПриСозданииНаСервере
ЭлементОтбора = Список.УсловноеОформление.Элементы.Добавить();
// Настраиваем ограничения для конкретных полей
Список.УстановитьОграниченияИспользованияВОтборе(Истина, "Комментарий");
Список.УстановитьОграниченияИспользованияВОтборе(Истина, "СостояниеЭДО");
Существует распространенное заблуждение, что отключение полнотекстового поиска ускоряет работу. На самом деле всё наоборот. Если полнотекстовый поиск включен и его индексы актуальны, платформа 1С при глобальном поиске сначала обращается к индексам ПП. Получив список идентификаторов (GUID) найденных объектов, она передает их в SQL-запрос через условие IN (...). Это работает в десятки раз быстрее, чем LIKE.
Проанализируем шаги по обслуживанию ПП:
Если диагностика показывает, что проблема именно в правах доступа (под администратором всё работает, под пользователем — нет), попробуем изменить режим работы RLS. В некоторых случаях перевод режима с «Производительного» на «Стандартный» и обратно помогает системе корректно перестроить внутренние механизмы разграничения прав.
Также стоит обратить внимание на количество ролей у пользователя. Посмотрим на этот нюанс подробнее: использование нескольких ролей, дающих доступ к одному и тому же объекту, может приводить к тому, что платформа объединяет условия RLS через оператор OR, что крайне негативно сказывается на плане запроса SQL. Постарайтесь минимизировать количество групп доступа для «проблемных» пользователей.
Часто проблема кроется в накопленных пользовательских настройках. Случайная сортировка по неиндексированной колонке или сложное условное оформление могут «добить» и без того тяжелый запрос. Выполним следующие действия:
Если вышеперечисленные методы не помогли, перейдем к анализу на уровне SQL-сервера. Выясним причину через мониторинг активных запросов. Нам нужно поймать запрос, который генерирует 1С в момент зависания.
Проанализируем план запроса (Execution Plan). Если мы видим оператор Nested Loops (вложенные циклы) при обработке сотен тысяч строк, значит, статистика SQL-сервера устарела. Рекомендуется выполнить обновление статистик для таблиц журналов документов и таблиц прав доступа:
-- Пример команды для обновления статистики по конкретной таблице (в консоли SQL)
UPDATE STATISTICS _DocumentJournal1234 WITH FULLSCAN;
Также обратим внимание на параметр MAXDOP (Max Degree of Parallelism). Для баз 1С рекомендуется значение 1, однако в некоторых случаях для тяжелых поисковых запросов на мощных серверах небольшое увеличение этого параметра может ускорить выполнение тяжелых сканирований таблиц.
Проблема тормозов в динамическом поиске КА 2.5 редко решается одним действием. Чаще всего это сочетание факторов. Наиболее эффективный алгоритм действий выглядит так:
Помните, что динамический список — это инструмент для отображения оперативных данных, а не для глубокого анализа всей базы данных. Обучение пользователей использованию конкретных фильтров вместо глобального поиска также является важной частью решения проблемы производительности.