Доброго времени суток.

Нужен совет.

Наткнулся в чужом коде на запрос ("ТестЗапроса1") "странной" конструкции. Взяли сомнения. Нужно ли такое усложнение кода.
Стало интересно. Сделал свой вариант ("ТестЗапроса2") и устроил замер производительности (результат прикрепил). В цикле 100 повторений каждого запроса.

В результате очень разное время выполнения запроса.

В таблице значений "ТбзДанные" около 100 строк. Справочник номенклатуры - 28220 строк.

Вопрос: "В каких случаях может быть оправдана такая реализация выборки?". Может при больших объёмах данных?

```1c
    Функция ТестЗапроса1(тбзДанные)
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    //
    тктЗапр =
    "ВЫБРАТЬ
    | ТбзДанные.КодТовара КАК КодТовара
    |ПОМЕСТИТЬ втДанные
    |ИЗ
    | &ТбзДанные КАК ТбзДанные
    |;
    |
    |////////////////////////////////////////////////////////////­////////////////////
    |ВЫБРАТЬ
    | СправочникНоменклатура.Ссылка КАК НоменклатураСсылка,
    | втДанные.КодТовара КАК КодТовара
    |ИЗ
    | Справочник.Номенклатура КАК СправочникНоменклатура
    | ВНУТРЕННЕЕ СОЕДИНЕНИЕ втДанные КАК втДанные
    | ПО СправочникНоменклатура.асИдентификаторГЛ = втДанные.КодТовара";
    //
    Запрос = Новый Запрос(тктЗапр);
    Запрос.УстановитьПараметр("ТбзДанные", тбзДанные);
    РезультатТест1 = Запрос.Выполнить();

    ВремяВыполненияЗапроса = ТекущаяУниверсальнаяДатаВМиллисекундах() - ВремяНачала;

    Возврат "Время выполнения запроса 1: " + ВремяВыполненияЗапроса;
    КонецФункции

    Функция ТестЗапроса2(тбзДанные)
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    //
    тктЗапр =
    "ВЫБРАТЬ
    | СправочникНоменклатура.Ссылка КАК НоменклатураСсылка,
    | СправочникНоменклатура.асИдентификаторГЛ КАК асИдентификаторГЛ
    |ИЗ
    | Справочник.Номенклатура КАК СправочникНоменклатура
    |ГДЕ
    | СправочникНоменклатура.асИдентификаторГЛ В(&ТбзДанные)";
    //
    Запрос = Новый Запрос(тктЗапр);
    Запрос.УстановитьПараметр("ТбзДанные", тбзДанные);
    РезультатТест2 = Запрос.Выполнить();

    ВремяВыполненияЗапроса = ТекущаяУниверсальнаяДатаВМиллисекундах() - ВремяНачала;

    Возврат "Время выполнения запроса 2: " + ВремяВыполненияЗапроса;
    КонецФункции
```
---
Всем спасибо.
Сделал, для себя, вывод, что лучше использовать временные таблицы. На малых объёмах потерять в скорости, но так как речь идёт о долях секунд - не критично. Зато, если вдруг, объёмы увеличатся - эффект будет заметен сильно.

Накидал обработку для теста. Кому интересно - пробуйте.
---
Первый запрос с ВТ, ваш без. Конечно для большого объема данных где используются ВТ, куда от этого денешься то.
---
Значит, если в таблице значений будет больше строк то использование временных таблиц оправдано? Сколько строк там должно былть?
Еще один момент. Влияет ли на скорость количество колонок и данных в них в таблице значений а скорость выполнения? Сейчас там только 1 колонка с кодами.
---
конечно, это правило хорошего тона использовать ВТ. На скорость влияет что вы выбираете запросом, а не то что есть по факту внешне, если в запросе будете перебирать много Выбрать ЧТОТО, то и скорость упадёт, как бы логично. Но лучше взять, наплодить к примеру копированием элементы, хотя бы тысч до 100, а дальше уже замером смотреть поведение одного и второго запроса, добавить информацию по отбору в запрос.
---
Ваш вариант дольше. Увеличьте количество элементов справочника еще раз в 10 - разница будет еще больше.

В (&Список) на больших объемах использовать не стоит.

Для полноты эксперимента нужен еще текст запроса преобразованный SQL)
---
Значит использование временных таблиц правильнее нежели конструкция "ГДЕ"? Скорость работы будет выше при больших объёмах данных?
---
Правильнее с точки зрения скорости да. И вообще использовать ГДЕ В & удобно когда у нас ограниченный и понятный по количеству элементов массив. Статусы например определенные отбирать и т.п.

Но по поводу правильности хз, сам не проверял, просто когда то чьи то слова принял за истину)
---
Проверьте без отладки и без повторений время выполнения первого и второго запроса в разных сеансах.
Какой тип имеет поле асИдентификаторГЛ, индексировано ли оно? Правильно ли я понял, что в справочнике присутствуют все записи с асИдентификаторГЛ из ТбзДанные?
---
Тип "асИдентификаторГЛ" - число, индексируется. Всем записям из "ТбзДанные" есть соответствия в справочнике "Номенклатура".

Провел ещё несколько тестов. Получается, что при количестве строк в таблице значений "ТбзДанные" больше 130 эффективность выполнения запросов меняется сильно. Первый запрос, с временной таблицей, в 2 раза быстрее чем второй с конструкцией "ГДЕ", а при количестве меньше 130 - первый медленнее в 3 раза.
---
а до 130 плюс минус одинаково?
---
Дополнил ответ. "при количестве меньше 130 - первый медленнее в 3 раза."
---
Всем спасибо.
Сделал, для себя, вывод, что лучше использовать временные таблицы. На малых объёмах потерять в скорости, но так как речь идёт о долях секунд - не критично. Зато, если вдруг, объёмы увеличатся - эффект будет заметен сильно.

Накидал обработку для теста. Кому интересно - пробуйте.
---
А кто-либо обратил внимание, что в ТестЗапроса1(тбзДанные) параметр - Таблица значений.
А в ТестЗапроса2(тбзДанные) уже внезапно Массив или СЗ.

Какая из двух не должна запускаться?
---
В функции с запросами предаётся таблица значений (в отладчике видно). Откуда массив?
---
В конструкции В(&Массив)
---
Я передаю туда таблицу значений. Может быть 1С сама преобразует типы. В любом случае смысл не в этом, а в алгоритме запроса. Так как разница на лицо.

Хотя, можно попробовать передать массив или список. Может быть результаты изменятся?
---
...Может быть 1С сама преобразует типы.
Получается что таки да.
Но вот я просто в удивлении, так как упустил момент когда платформа была явно против того, чтобы в конструкцию В() в запросе разработчик вставлял ТЗ и хотела только СЗ или Массив, о чём собственно говорят и консоли запросов, в которых В() нужно класть СЗ.
А теперь платформа непротив ТЗ, и даже непротив ТЗ с несколькими колонками.
И кто скажет с какой версии это произошло? Ну явно же такого не было.