Многие администраторы и разработчики 1С сталкиваются с ситуацией, когда поиск в динамических списках (например, в списке заказов или заявок) начинает занимать недопустимо много времени — от 10 до 40 секунд и более. В логах технологического журнала это выглядит как тяжелый SQL-запрос с оператором LIKE. Разберем, почему это происходит и как полнотекстовый поиск (ППД) помогает решить эту проблему при правильной настройке.
Рассмотрим ситуацию: пользователь вводит часть строки в поле поиска динамического списка. Если механизм полнотекстового поиска отключен или его индекс не актуален, платформа 1С вынуждена транслировать этот запрос напрямую в СУБД SQL Server. Запрос приобретает вид WHERE _Description LIKE '%интер%'.
Проанализируем техническую сторону: оператор LIKE с процентом в начале строки делает невозможным использование обычных индексов SQL. СУБД приходится выполнять операцию Full Table Scan — полное сканирование таблицы. На таблицах объемом в сотни тысяч или миллионы записей это неизбежно приводит к многосекундным задержкам, как в нашем примере, где поиск по 37 000 документов занял 42 секунды. При включенном и актуальном ППД система сначала получает список подходящих ссылок из своего собственного индекса, а затем быстро выбирает их из SQL по первичному ключу, что сокращает время поиска до 1–2 секунд.
Для эффективной работы системы нам необходимо настроить два разных процесса. Выясним разницу между ними, чтобы избежать перегрузки сервера.
Рассмотрим оптимальный график работы этих заданий для базы со средней нагрузкой (около 100 пользователей и 300 документов в день):
Шаг 1. Настройка обновления индекса. Настроим частое выполнение, чтобы пользователи видели актуальные данные в поиске почти мгновенно. Рекомендуемое расписание: каждые 60–300 секунд (1-5 минут). Это обеспечит актуальность данных без видимого влияния на общую производительность.
Шаг 2. Настройка слияния индекса. Вынесем эту операцию на период минимальной активности. Рекомендуемое расписание: один раз в сутки ночью (например, в 03:00). В некоторых случаях при очень интенсивном документообороте слияние можно запускать дважды в сутки, но строго вне часов пик.
Одна из главных причин, почему "ППД тормозит" — это попытка индексировать всё подряд. Проанализируем состав метаданных в конфигураторе. Нам не нужно искать всё во всём. Для оптимизации выполним следующие действия:
Полнотекстовый поиск и установим значение Использовать в Не использовать.Посмотрим на ситуацию со стороны системного администрирования. Файлы индекса ППД хранятся непосредственно в каталоге сервера 1С (в папке соответствующей базы). Для высоконагруженных систем крайне желательно:
Иногда полезно проверить состояние индекса или программно запустить его обновление. Для этого в языке 1С предусмотрен менеджер ПолнотекстовыйПоиск. Разберем пример кода для принудительного обновления индекса:
// Проверим, разрешен ли полнотекстовый поиск в системе
Если ПолнотекстовыйПоиск.ПолучитьРежим() = РежимПолнотекстовогоПоиска.Разрешить Тогда
// Запускаем обновление индекса (порционно)
ПолнотекстовыйПоиск.ОбновитьИндекс(Ложь, Истина);
КонецЕсли;
В данном примере метод ОбновитьИндекс с параметрами (Ложь, Истина) позволяет выполнить частичное обновление только измененных данных в фоновом режиме.
Резюме: Не стоит бояться ППД. Те 42 секунды, которые вы видите в логах — это результат работы SQL без помощи индекса. Включите ППД, настройте обновление раз в 2 минуты, а слияние — глубокой ночью, и поиск в списках станет мгновенным.