УТ 11.4
Есть справочник НоменклатураПоставщиков 350тыс наименований

Простой запрос на получения всех номенклатур выполняется 0,9с
Запрос с ПОДОБНО одного слова уже 2,5 сек.
Если запрос сложнее типа полнотекстового поиска то еще больше.

Возможно ли как то ускорить поиск, а то например поиск десятка товаров превращается в сплошное ожидание :(

отключи иерархию и дерево в представлении списка

ну и сделай роль без RLS

ну и еще

1с динамические списки индексирует на собственном сервере, то есть его родной поиск работает не через SQL а через собственные индексы которые лежат в каталоге сервера 1с, перенеси его на SSD и будет значительно быстрее

(1) Скорость замерял через "Консоль запросов" т.е. соответственно насколько понимаю иерархия и дерево тут не применялось.

(2) Сейчас тестирую именно на SSD.

Хотелось бы понять, возможно ли вообще ускорить раз в 10 например, или же с таким справочником только на несколько процентов

(3) динамический список использует ДРУГОЙ запрос, там результат выдается кусками, по этому замер в консоли некоректный...

в динамическом списке рекомендуется использовать ОТБОРЫ а не параметры

(5) Спасибо, буду изучать.

(5) "в динамическом списке рекомендуется использовать ОТБОРЫ а не параметры " - откуда дрова?

можно привязать группы к пользователям, можно использовать кодирование групп

0.9с это под полными правами запрос вида ВЫБРАТЬ Ссылка ПОМЕСТИТЬ ВТ Из Справочник.НоменклатураПоставщиков?

Используется РЛС? Если используется, можно ускорить, отключив его или поставив производительный режим.

Это подчиненный справочник, у него все индексы выглядят как-то так: Разделители + Владелец +...
Соответственно при поиске, чтобы использовался индекс, нужно делать отбор по владельцу.

(9) Хотя про индексы я погорячился. Индексы без владельца тоже должны быть.

(0) Подобно не очень хорошо работает в запросах, нужно использовать его правильно.
https://its.1c.ru/db/v8std/content/658/hdoc

(11) Подобно работает хорошо если ПОДОБНО "строка%"
начало строки должно совпадать. Это в статье написано которую Вы скинули.
По САБЖу предлагаю 1) Посмотреть структуру хранения БД. Может можно еще накинуть индекс. Может не в самом наименовании хранить данные, а новый реквизит сделать, дублировать наименование и добавить индекс.
2) Посмотреть на Сервере СУБД план запроса который выполняется. Может вообще статистику обновить. Собрать данные по загрузке оборудования. Может у вас сервер надо менять.
3) Посмотреть в сторону регистра с измерением наименования и ресурсом ссылка - тогда отбор будет по перовому измерению. Искать по регистру. Дублировать туда данные при записи справочника. Опять же если не будет конструкции %Че-то там
4) Написать прямой запрос к СУБД и вызывать его из 1С

Если простой запрос на 350к выполняется 0.9 сек это уже не очень хорошо, сервак не супертоп

(0) Да, можно.

https://wonderland.v8.1c.ru/blog/novye-funktsii-yazyka-zaprosov-i-sistemy-komponovki-dannykh/?sphrase_id=663464#:~:text=%D0%A1%D0%BE%D0%BA%D1%80%D0%9B%D0%9F(TrimAll)%20%E2%80%93%20%D0%BE%D1%82%D0%B1%D1%80%D0%BE%D1%81%D0%B8%D1%82%D1%8C%20%D0%BD%D0%B5%D0%B7%D0%BD%D0%B0%D1%87%D0%B0%D1%89%D0%B8%D0%B5 ,%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D1%82%D1%8C%20%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D0%B5%20%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%B0%20%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D1%8B%20%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B8.

Система компоновки данных
В язык выражений системы компоновки данных добавлены новые функции:

СокрЛ(TrimL) – отбросить незначащие пробелы слева.

СокрП(TrimR) – отбросить незначащие пробелы справа.

СокрЛП(TrimAll) – отбросить незначащие пробелы слева и справа.

Лев(Left) – получить первые слева символы строки.

Прав(Right) – получить первые справа символы строки.

СтрНайти(StrFind) – найти подстроку в строке (без учета регистра).

ВРег(Upper) – преобразует все символы строки в верхний регистр.

НРег(Lower) – преобразует все символы строки в нижний регистр.

СтрЗаменить(StrReplace) – заменяет все вхождения подстроки на другую подстроку (без учета регистра).

НСтр(NStr) – получает строку на языке пользователя (аналогично тому, как работает метод НСтр глобального контекста). Параметры:

ИсходнаяСтрока – строка, содержащая строки на разных языках (например, "ru = 'Добрый вечер!'; en = 'Good Evening!'").

КодЯзыка (необязательный) – строка с кодом языка, на котором нужно получать строку. Если не указан - строка получается на языке текущего пользователя.

Скажем так, СокрЛП или НРег или СтрНайти, работает в разы шустрее "Подобно"

все советы из (12) так себе.

1. Сразу видно ТС молодой и зеленый, и ему разбиратся с индексами и чем-то более сложном не айс
2. Не нужно изобретать велосипед, динамический список очень хороший объект и стоит использовать его ШТАТНЫЕ возможности, сделать лучше штатного в теории можно, но это сравнимо полету на луну.
3. Может стоит вообще отказатся от сложных запросов и решить проблемму административно? Или предложить вариант работы пользователя где таких запросов будет мало?

сейчас выяснится, что база файловая :)

(15) Спасибо, больше не буду советовать))

(12) советы все верные
1. Это придется сделать, когда-то надо начинать
2. Никаких велосипедов. Если проблема с СУБД то будет тормозить даже если там 1000 строк
3. Может. А может попробовать решить проблему с которой пришел ТС
Из (0) и дальнейшего обсуждения я не вижу слово динамический список из уст ТС где вы все взяли его? Я так понял все тесты на которые жалуется ТС были выполнены из консоли.

(0) А смысл ускорять? если бы минута была поиска.

(18) Действительно. Че-то не выспался( Чертовы соседи шумели ночью

(19)>А смысл ускорять? если бы минута была поиска.
Допустим клиент работает с таблицей и перебирает там какие-то позиции. На каждый щелчок мышью подбирается определенный набор данных основанный на текущей строке. В этом случае, если после каждого клика нужно ждать одну или (жесть ккакая) 2.5 секунд. Через полчаса работы захочется ударить монитор кулаком. А через час точно ударишь. Так никаких мониторов не напасешься.

(22) так вопрос в подготовке данных и поиск уже по этим данным, а не по всей базе 1С - это ведь существенно ускорит поиск

(0) Какая задача стоит?
Полностью сценарий работы пользователя можно описать?

Может в вашем случае быстрее будет работать 1С-овский полнотекстовый поиск с включенным ограничением по области поиска (только справочник Номенклатура поставщиков), в привилегированном режиме без получения описания и представления. А уже с полученным списком поиска работать дальше.

(22)Может оказаться, что непонятно заранее, что надо готовить. А готовить все возможные варианты будет занимать слишком много или времени или ресурсов или и того и другого или будет слишком быстро терять актуальность. Но какой-то заранее проиндексированный регистр(который формируется ни перед открытием формы, а в процессе записи данных) в помощь вполне себе рабочая схема.

(24) Полностью сценарий работы пользователя можно описать?