Как работает поиск в динамических списках и почему он зависит от полнотекстового поиска

Программист 1С v8.3 (Управляемые формы) 1С:Документооборот IT и автоматизация бизнеса
← На главную

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

Два режима работы поиска: SQL против ППС

Для начала проанализируем ситуацию, как именно платформа «1С:Предприятие 8.3» обрабатывает поисковый запрос, введенный в поле Список.СтрокаПоиска. Начиная с версии платформы 8.3.10, поиск в динамических списках стал гибридным. Платформа автоматически выбирает один из двух путей:

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

Рассмотрим подробнее случай с 1С:Документооборот 3.0. Списки документов в этой системе строятся на сложных запросах, объединяющих множество таблиц. В таких условиях использование LIKE практически невозможно из-за таймаутов, поэтому платформа принудительно отдает предпочтение полнотекстовому индексу.

Почему в копии базы поиск работает, а в рабочей — нет?

Выясним причину этого феномена. Когда вы создаете копию базы (особенно через выгрузку и загрузку .dt), файлы полнотекстового индекса не переносятся автоматически. При первом запуске копии платформа видит, что индекс отсутствует или неактуален. В этом случае срабатывает алгоритм отката: платформа временно переключается на поиск через SQL.

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

Где физически хранятся данные поиска

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

Обычно файлы располагаются в каталоге служебных файлов кластера: C:\Program Files\1cv8\srvinfo\<ID_кластера>\<ID_базы>\1Cv8FTxt. В этой папке находятся файлы с расширениями:

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

Технические причины сбоев поиска

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

  1. Фрагментация и накопление «мусора»: При интенсивном документообороте данные постоянно меняются. Индекс ППС постепенно фрагментируется. В этом случае стандартное обновление может не помочь, требуется процедура СлияниеИндекса или полная переиндексация.
  2. Лимиты индексации: Полнотекстовый поиск имеет ограничение на длину слова (по умолчанию около 32 символов). Если пользователь пытается найти документ по сверхдлинному уникальному идентификатору или артикулу, ППС может его проигнорировать.
  3. Настройки метаданных: Проверьте в Конфигураторе свойство объекта (например, Документ.ВходящийДокумент). Свойство ПолнотекстовыйПоиск должно быть установлено в значение Использовать. Если оно выключено, поиск по этому объекту в общем динамическом списке будет крайне медленным, так как платформа не сможет использовать индекс.

Как настроить регламентное обслуживание

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

1. Обновление полнотекстового индекса. Должно запускаться часто (раз в 1-5 минут). Оно добавляет в индекс только новые или измененные данные.

2. Слияние полнотекстового индекса. Более тяжелая операция, которую рекомендуется выполнять в периоды низкой нагрузки (например, ночью). Она объединяет порции данных в основной индекс, оптимизируя скорость поиска.

Рассмотрим пример программного контроля состояния индекса:


СостояниеППС = ПолнотекстовыйПоиск.ПолучитьСостояние();
Если СостояниеППС = СостояниеПолнотекстовогоПоиска.ТребуетсяОбновление Тогда
    ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);
КонецЕсли;

Рекомендации по диагностике и решению

Если поиск перестал работать, выполните следующие действия:

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

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

← На главную