Многие технические специалисты сталкиваются с ситуацией, когда в крупных базах «1С:Предприятие 8.3» стандартный поиск в списках (вызываемый по Ctrl+F или через строку поиска) начинает работать крайне медленно. При этом глобальный поиск (Ctrl+Shift+F) выдает результаты мгновенно. В этой статье мы подробно разберем, почему так происходит, как механизмы платформы взаимодействуют с SQL-сервером и что нужно сделать, чтобы ускорить работу пользователей в формах списка.
Для начала проанализируем, почему существует разница в скорости. Когда мы используем Глобальный поиск, система обращается напрямую к файлам полнотекстового индекса, которые хранятся на сервере 1С. Этот поиск не ограничен структурой какой-то конкретной таблицы или динамического списка. Он просто находит вхождения слов и выдает ссылки на объекты.
Однако, когда пользователь нажимает Ctrl+F в форме списка (например, в списке счетов-фактур или заказов), платформа пытается выполнить более сложную задачу. Ей нужно не просто найти строку, а отфильтровать текущий динамический список. Это означает, что результат поиска должен быть совмещен с:
Если системе не удается эффективно «скрестить» полнотекстовый индекс с запросом списка, она отказывается от ППД (полнотекстового поиска данных) и переходит к классическому SQL-запросу с оператором LIKE %Текст%. На таблицах объемом более 500 000 записей это неминуемо приводит к сканированию всей таблицы и задержкам в 30-60 секунд.
Рассмотрим основной фактор, влияющий на выбор платформой механизма поиска. Для того чтобы полнотекстовый поиск вообще мог быть задействован в динамическом списке, должны быть соблюдены определенные условия в конфигураторе. Разберем их по шагам.
Во-первых, у динамического списка обязательно должна быть указана Основная таблица. Если ваш список построен на произвольном запросе, но поле «Основная таблица» оставлено пустым, платформа не сможет сопоставить данные индекса ППД с таблицей базы данных. В этом случае поиск всегда будет идти через SQL-запрос LIKE.
Во-вторых, проанализируем текст самого запроса. Полнотекстовый поиск в списках часто отключается автоматически, если запрос содержит:
LEFT JOIN с виртуальными таблицами остатков или оборотов.UNION или UNION ALL.ВЫБОР КОГДА ... ТОГДА.Если в вашем списке присутствуют такие элементы, попробуйте упростить запрос или вынести сложные вычисления в процедуру ПриВыводеСтроки (хотя это может замедлить прокрутку, поиск станет работать корректнее через индекс).
Выясним причину, почему даже при правильных настройках списка поиск может игнорировать индекс. Каждое поле (реквизит), по которому предполагается поиск, должно иметь включенное свойство Полнотекстовый поиск (значение «Использовать»).
Если вы уверены, что настройки в конфигураторе верны, необходимо проверить состояние самого индекса в пользовательском режиме. Выполним следующие действия:
В некоторых случаях индекс может быть поврежден или фрагментирован. В такой ситуации стандартное обновление не поможет. Рекомендуем выполнить полную очистку и перестроение:
// Пример программного управления полнотекстовым поиском
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина); // Истина — для полного перестроения
Проанализируем специфику работы платформы версии 8.3.13 и выше. В этих релизах была замечена особенность: если в строке поиска присутствуют спецсимволы (тире, дефисы, слэши), механизм ППД может работать некорректно. Например, при поиске номера документа АБ-000123 система может воспринять дефис как оператор «исключить слово» (NOT), если не заключить строку в кавычки.
Также стоит обратить внимание на настройку «Поиск при наборе». Если в настройках пользователя стоит режим «Искать везде», 1С вынуждена перебирать все колонки. Посмотрим, как это изменить: в окне поиска (Ctrl+F) выберите конкретную колонку (например, «Номер») вместо значения «Везде». Это принудит систему использовать индекс только по конкретному полю, что значительно ускоряет получение результата.
Несмотря на то что полнотекстовый индекс хранится вне SQL, итоговую выборку все равно делает база данных. Если статистика SQL-сервера устарела, оптимизатор может построить неверный план запроса при получении данных по списку идентификаторов, полученных из ППД. Разберем, что нужно сделать системному администратору:
UPDATE STATISTICS для таблиц базы данных 1С.Как ни странно, в некоторых конфигурациях (особенно на файловых базах или старых релизах платформы) помогает обратное действие — полное отключение полнотекстового поиска. В этом случае 1С перестает пытаться анализировать файлы индекса и сразу переходит к SQL-запросу. Если при этом ваши SQL-таблицы хорошо проиндексированы по ключевым полям (Номер, Дата, Контрагент), поиск через LIKE %Текст% по конкретной колонке может отработать быстрее, чем попытка системы сопоставить данные из внешнего индекса ППД.
Для этого в свойствах конфигурации установите «Использовать полнотекстовый поиск» в значение «Не использовать» и проверьте скорость работы Ctrl+F. Если поиск стал мгновенным — значит, проблема была в накладных расходах на обслуживание и чтение файлов индекса ППД.
Подводя итог, для устранения тормозов при поиске в списках мы рекомендуем придерживаться следующего алгоритма:
JOIN) в запросе списка.Соблюдение этих правил позволит вернуть комфортную скорость работы пользователям даже в очень объемных списках документов.