Что быстрее отработает:

"ВЫБРАТЬ Спр.Ссылка Из Справочник.Справочник КАК Спр ГДЕ Спр.Реквизит В (ВЫБРАТЬ тз.Ссылка ИЗ тз)"

или

"ВЫБРАТЬ Спр.Ссылка ИЗ Тз ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Справочник КАК Спр ГДЕ тз.Ссылка = Спр.Реквизит"

Если Спр.Реквизит - индексированное поле.

Произведи замер производительности, да сообщи здесь

(0) Произведи замер и доложи

(0) на ms sql скорее всего примерно одинаково будет

(0) Один из стандартных вопросов про коня в вакууме...
Если есть несколько разных спосбов получить результат, то, почему-то, некоторые думают, что один из этих способов обязательно лучше всех в любом случае. Не понятно только зачем тогда нужны остальные способы...
Тесты, и только тесты на вашей конкретной системе и конкретных данных могут выявить победителя.

У меня быстрее первый вариант, но я не понимаю почему. Я списываю все на файловую базу.

(5) с файловой базой до свидания

(0) писать условия соединения в секции не ГДЕ не есть комильфо

для небольшого по размеру параметру оператор "В" конвертируется в много "ИЛИ"

соединение даже по индексированому полю вполне может пойти по фулскан ....


по этому все зависит от конкретного контекста...

v8: Временные таблицы и индексы в запросах

Я понимаю, что все от конкретного случая, но в вакууме то как правильно сделать?)) Смысл в том, что тз может быть и 2 строчки и 20000.

с файловой базой до свидания

(10) если тогда иначе конецесли

Ну я могу тестировать только на файловой, но работать это будет на сервере.

Была бы у меня возможность замерять производительность в рабочей базе, я бы вам не писал пасаны;)

(13) на сервере, но в файловой?

(14) Проблема в чем?Сделать копию на скуле

(16) Нет скуля у меня)

(15) нет все православно, на скуле.

(17) так и разработку надо на сиквеле вести тогда. очень сильно отличается исполнение запросов.

(19) Это я тоже понимаю, но есть что есть. Скуль в цоде, цод в жо..

(17) Ну так поставь.

Соединение должно быть внутреннее по полю с индексом

Я хотел чтобы умный человек написал, что то вроде: ГДЕ быстрее при маленькой тз, соединение быстрее при большой тз, потому что..

а не вот это вот все) Ставить скуль, замерять производительность, смотреть планы, не так быстро как хотелось бы)

(21) сервер 1с тоже "поставь"?

ГДЕ и соединение будут ВСЕГДА быстрее по равенству, медленнее по диапазону и больше-меньше-равно.

(22) А вы уверены что внутренее быстрее левого? или это про NULLи.
(25) Это понятно, но как это относится к моей задаче?)

(24) А почему бы и нет? У меня стоит и не жужжит.
В (19) правильно написано.

(26) Поверь, в 99% случаях да.

(27) Локальная машина не сервер. Все равно не те ощущения))

Я про SQL и говорю

(23) так субд может один план выбрать для этих двух запросов

(28) Кто-то мне говорил, что внутренее это полное, только с доп условиями, я с тех пор избегаю если могу.

(31) НУ я не хочу под конкретный оптимизатор писать) Мне интересно, что в общем случае будет.

(32) это логика работы, а не физика исполнения. все соединения кроме кросса это декартово с условием. по логике работы.

///////////1////////////
ВЫБРАТЬ тз.Ссылка поместить тз ИЗ &тз КАК тз;
ВЫБРАТЬ Номенклатура.Ссылка
ИЗ Справочник.Номенклатура КАК Номенклатура
ГДЕ Номенклатура.ЦеноваяГруппа В (ВЫБРАТЬ тз.Ссылка ИЗ тз)
    
Fields:(
    Номенклатура_T1.Ссылка
)
Справочник.Номенклатура (Номенклатура_T1) RANGE SCAN USING INDEX (_REFERENC31_BYFIELD6377_RR) (1 fields)
WHERE
        Номенклатура_T1.ЦеноваяГруппа IN(
(SELECT
                Fields:(
                    T2._Q_000_F_000RRef
                )
                #T1f883794753d47fc99c0ecf4e48411bf (T2) FULL SCAN


                WITHOUT DUPLICATES
                )            )

Statistics: RecordsScanned = 45, ParseTime = 0, ExecuteTime = 0, BuffersMemory = 40044, ResultRecords = 42, RecordSize = 18
///////////2////////////
ВЫБРАТЬ тз.Ссылка поместить тз ИЗ &тз КАК тз;
ВЫБРАТЬ Номенклатура.Ссылка
ИЗ Тз как тз ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
по тз.Ссылка = Номенклатура.ЦеноваяГруппа
Fields:(
    Номенклатура_T2.Ссылка
)
#T5f9298c02e64451faba9ba7723f1d943 (T1) FULL SCAN

NESTED OUTER LOOP
Справочник.Номенклатура (Номенклатура_T2) RANGE SCAN USING INDEX (_REFERENC31_BYFIELD6377_RR) (1 fields)
WHERE
        (T1._Q_000_F_000RRef = Номенклатура_T2.ЦеноваяГруппа)

Statistics: RecordsScanned = 45, ParseTime = 0, ExecuteTime = 0, BuffersMemory = 40044, ResultRecords = 42, RecordSize = 18
RANGE SCAN USING INDEX vs Nested loop RANGE SCAN USING INDEX

быстрее отработает если ТЗ заменить на подзапрос, с условием что там достаточно простой запрос. без создания врем. таблицы тогда обойдется исполнение.

(35) Я правильно понял, что первый лучше, потому что цикла нет?

Несмотря на кучу бесполезных комментариев вопрос на самом деле интересный.
Возможно, тебе помогут в нем разобраться эти ссылки:
https://www.sqlite.org/eqp.html
https://www.sqlite.org/queryplanner.html
https://stackoverflow.com/questions/1454188/how-can-i-analyse-a-sqlite-query-execution

Инструмены разработчика - Консоль запросов - Запрос результата - Трасса

Когда раскуришь опкоды файлового движка бд - ты сможешь ответить на свой вопрос.

(37) по итоговой стоимости посмотри