Работа с большими объемами данных в 1С:Предприятие 8.3 часто ставит перед разработчиком задачу оптимизации поиска. Когда справочник, такой как НоменклатураПоставщиков, разрастается до 350 000 и более наименований, стандартные методы поиска через оператор ПОДОБНО начинают работать крайне медленно. В этой статье мы подробно разберем, почему возникают задержки и какие инструменты помогут ускорить поиск в разы.
Прежде всего, проанализируем ситуацию. Если простой запрос на выборку всех данных выполняется за 0,9 секунды, а добавление условия ПОДОБНО увеличивает время до 2,5 секунд и выше, это сигнализирует о неэффективном использовании индексов СУБД. В большинстве случаев это происходит из-за "фулл-скана" (Full Table Scan) — ситуации, когда серверу СУБД приходится перебирать все записи таблицы, чтобы найти совпадение строки в середине текста.
Рассмотрим специфику работы индексов в SQL. Индекс по строковому полю эффективно работает только в том случае, если мы ищем по началу строки. Если ваше условие выглядит как ПОДОБНО "%Текст%", индекс не будет использован. Однако, если мы изменим подход на ПОДОБНО "Текст%", система сможет применить индекс, что значительно ускорит выполнение запроса.
Разберем пример правильного формирования условия в коде:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НоменклатураПоставщиков.Ссылка КАК Ссылка
|ИЗ
| Справочник.НоменклатураПоставщиков КАК НоменклатураПоставщиков
|ГДЕ
| НоменклатураПоставщиков.Наименование ПОДОБНО &ПоисковаяСтрока";
// Чтобы использовать индекс, строка должна начинаться с искомого слова
Запрос.УстановитьПараметр("ПоисковаяСтрока", Объект.СтрокаПоиска + "%");
Результат = Запрос.Выполнить();
Начиная с современных версий платформы 8.3, в языке запросов и СКД появились функции, которые работают быстрее стандартного оператора сравнения в определенных сценариях. Рассмотрим такие функции, как СтрНайти, СокрЛП и ВРег. Они позволяют более гибко манипулировать строками на уровне сервера БД.
Проанализируем преимущества: использование СтрНайти в выражениях СКД или программная обработка строк перед сравнением часто показывают лучшие результаты по сравнению с тяжелыми конструкциями ПОДОБНО, особенно при правильной нормализации данных в базе.
Если пользователю необходим поиск по любой части слова или по нескольким словам в произвольном порядке, стандартные SQL-индексы бессильны. В этом случае мы рекомендуем использовать механизм ПолнотекстовыйПоиск. Этот механизм создает собственные индексы в каталоге сервера 1С, которые оптимизированы именно под текстовый поиск.
Разберем шаги по внедрению ППС для конкретного справочника:
НоменклатураПоставщиков и необходимых реквизитов (Наименование, Артикул).ПолнотекстовыйПоиск.СоздатьСписок() для программного получения результатов. Это работает значительно быстрее любого сложного запроса.Рассмотрим еще один профессиональный метод — создание вспомогательного регистра сведений. Суть метода заключается в "разбивке" каждого наименования на отдельные слова при записи элемента справочника.
Посмотрим на структуру такого решения:
ИндексНаименований с измерениями Слово (строка, 50 символов) и Объект (Ссылка на справочник).ПередЗаписью или ПриЗаписи очищаем старые записи в регистре и записываем каждое слово из наименования отдельной строкой.Слово. Поскольку измерения всегда индексируются, поиск по конкретному слову происходит мгновенно.
// Пример разбивки и поиска
СловаПоиска = СтрРазделить(СтрокаПоиска, " ", Ложь);
Запрос.Текст = "ВЫБРАТЬ Объект ИЗ РегистрСведений.ИндексНаименований ГДЕ Слово В (&Слова)";
Запрос.УстановитьПараметр("Слова", СловаПоиска);
Если поиск осуществляется в форме списка, важно понимать, как 1С работает с объектом ДинамическийСписок. Выясним причину замедления: часто разработчики используют произвольный запрос с параметрами, что мешает платформе эффективно строить SQL-план.
Рекомендации для динамических списков:
КомпоновкаДанных отборами.Проанализируем ситуацию на уровне системных настроек. Если вы используете PostgreSQL, обратите внимание на расширение pg_trgm (триграммы). Оно позволяет эффективно индексировать поиск по вхождению подстроки. В среде MS SQL Server крайне важно следить за статистикой и фрагментацией индексов. При частом обновлении 350 тысяч записей индексы быстро фрагментируются, что "ослепляет" оптимизатор запросов.
Также проверьте работу RLS (Ограничение доступа на уровне записей). Если для пользователя включен RLS, к каждому вашему запросу 1С неявно добавляет сложные условия проверки прав. Попробуйте выполнить поиск под полными правами: если скорость вырастет в разы, значит, проблему нужно решать через переход на производительный режим RLS или оптимизацию ролей доступа.
Ускорение поиска в 10 раз — вполне достижимая цель для справочника в 350 000 записей. Для этого мы рекомендуем комбинированный подход: оптимизацию строковых условий в запросах, обязательное использование полнотекстового поиска 1С и, в наиболее критических узлах, переход на архитектуру с предварительной индексацией слов в регистрах сведений. Разберем и внедрим эти методы последовательно, начиная с самых простых настроек индексов, и ваша система станет значительно отзывчивее для конечного пользователя.