Как ускорить поиск в 1С: практическое руководство

Медленный поиск в 1С — одна из самых частых жалоб пользователей: справочник контрагентов открывается по полминуты, подбор номенклатуры «подвешивает» документ, а поиск документа по номеру занимает минуты. Причины почти всегда сводятся к нескольким типовым проблемам: отключённый или устаревший полнотекстовый индекс, поиск по подстроке вместо точного совпадения, неоптимальные запросы в доработанных формах и недостаток ресурсов сервера.

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

Важно понимать различие: «поиск» в 1С — это не один механизм. Полнотекстовый поиск по данным, поиск в полях ввода (динамический список справочника), поиск строки в табличной части и поиск через запросы в коде работают по-разному и ускоряются разными средствами.

Определите, какой именно поиск тормозит

Прежде чем что-то менять, зафиксируйте симптомы. Медленный поиск по строке в форме списка справочника — это одна проблема, а медленный полнотекстовый поиск из панели — совсем другая. Попросите пользователя показать конкретное действие и замерьте время: сколько секунд занимает операция сейчас. Это понадобится, чтобы потом проверить эффект от изменений.

Типовые сценарии выглядят так: поиск контрагента по названию в поле ввода, поиск документа по номеру, поиск товара по артикулу, полнотекстовый поиск по всей базе, поиск в журнале документов с отбором. Для каждого из них есть свой основной инструмент ускорения.

Включите и настройте полнотекстовый поиск

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

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

Учтите ограничение: полнотекстовый поиск ищет по словам целиком, а не по произвольным фрагментам. Поиск «Иван» найдёт «Иванов», но поиск «вано» — нет. Объясните это пользователям, чтобы они формировали запросы правильно.

1. 1
   Откройте Администрирование — Обслуживание — Полнотекстовый поиск
2. 2
   Включите полнотекстовый поиск и запустите полное обновление индекса
3. 3
   Настройте расписание регламентного задания обновления индекса
4. 4
   Проверьте поиском свежий документ после очередного обновления
5. 5
   Убедитесь, что задание выполняется без ошибок в журнале регистрации

Ускорьте поиск в полях ввода и списках справочников

Когда пользователь начинает вводить название контрагента, платформа выполняет запрос к справочнику. Скорость этого запроса зависит от двух вещей: способа поиска и наличия индекса по полю поиска. По умолчанию во многих конфигурациях используется поиск «по части строки» — с символом % в начале шаблона. Такой запрос не может использовать обычный индекс и при большом объёме справочника сканирует всю таблицу.

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

Второе действие — убедиться, что реквизит, по которому ищут (наименование, артикул, ИНН), участвует в индексе. В конфигураторе у реквизита есть свойство «Индексировать». Для полей, по которым регулярно ищут и отбирают, индексирование должно быть включено. После изменения индексов требуется реструктуризация — делайте её в нерабочее время и только с резервной копией.

Проверьте индексы и запросы в доработках

Если база дорабатывалась, медленный поиск часто живёт в самописных запросах. Типичные проблемы: соединение таблиц без индексированных полей, отбор по выражению (например, функция над полем в условии), выборка «ВЫБРАТЬ *»-стиля с лишними полями, виртуальные таблицы без параметров отбора. Такие запросы хорошо работают на тестовой базе и деградируют по мере роста данных.

Для диагностики используйте технологический журнал с событием DBMSSQL/DBPOSTGRS и замером длительности — он покажет, какие запросы выполняются дольше всего. Затем план запроса на стороне СУБД покажет, используется ли индекс или выполняется полное сканирование таблицы. Если видите Scan там, где ожидался Seek, — запросу не хватает подходящего индекса или условие написано так, что индекс не применяется.

Частый приём ускорения — переписать условие так, чтобы поле таблицы стояло «чисто»: вместо ПОДСТРОКА(Наименование, 1, 5) = &Фрагмент искать Наименование ПОДОБНО &Фрагмент + «%». Вместо отбора по функции от даты — по диапазону дат. Эти изменения позволяют СУБД использовать индекс.

// Плохо: поиск по подстроке, индекс не используется
ГДЕ Наименование ПОДОБНО &"%" + Фрагмент + "%"

// Лучше: поиск с начала строки, индекс работает
ГДЕ Наименование ПОДОБНО &Фрагмент + "%"

Оптимизируйте поиск документов и работу с журналами

Поиск документа по номеру обычно быстрый, если номер индексирован (в типовых конфигурациях это так). Но пользователи часто ищут документы через журнал с отборами по контрагенту, организации, сумме. Здесь помогает правильная настройка: критерии отбора должны строиться по индексированным реквизитам, а в форме журнала стоит ограничивать период просмотра — «за месяц» вместо «за всё время».

На больших базах полезно настроить типовые отборы и сохранить их как варианты списка, чтобы пользователи не строили произвольные отборы по неиндексированным полям. Также проверьте, не включён ли в журнале вывод большого числа колонок с данными через точку — каждая такая колонка добавляет соединения в запрос динамического списка.

Если поиск по строке в табличной части или в форме списка выполняется встроенным диалогом (Ctrl+F), помните: он ищет только среди уже загруженных строк. Для поиска по всей таблице нужны отборы или полнотекстовый поиск.

Проверьте серверную инфраструктуру

Никакая настройка поиска не поможет, если серверу не хватает ресурсов. Для клиент-серверной 1С критичны: объём оперативной памяти под СУБД, быстрые диски под базу и tempdb, регулярное обновление статистики и обслуживание индексов на стороне СУБД. Фрагментированные индексы и устаревшая статистика заставляют оптимизатор выбирать плохие планы даже для простых запросов поиска.

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

Отдельно проверьте версию платформы: в новых релизах регулярно улучшают механизмы поиска и работу динамических списков. Обновление платформы иногда даёт ускорение без каких-либо изменений конфигурации.

Как проверить, что поиск стал быстрее

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

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

Частые вопросы