Подскажите, что лучше с точки зрения производительности : внутреннее соединение или вложенный запрос в условиии?

Например :

ВЫБРАТЬ
    |    Номенклатура.Ссылка
    |ИЗ
    |    Справочник.Номенклатура КАК Номенклатура
    |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
    |        ПО Номенклатура.Ссылка = ЗначенияКатегорийНоменклатуры.Номенклатура
    |        И ЗначенияКатегорийНоменклатуры.Категория = &Категория

ИЛИ

"ВЫБРАТЬ
    |    Номенклатура.Ссылка
    |ИЗ
    |    Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |    Номенклатура.Ссылка В
    |            (ВЫБРАТЬ
    |                ЗначенияКатегорийНоменклатуры.Номенклатура
    |            ИЗ
    |                РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
    |            ГДЕ
    |                ЗначенияКатегорийНоменклатуры.Категория = &Категория)

Пример утрирован, не говорите, что нужно сделать просто выборку из регистра значений категорий :-)

Зависит от размеров таблиц.

Правильный ответ даст тебе скд-профилер.

(0) внутреннее соединение однозначно. Оптимизатору так легче выбрать план запроса

Соединение ОБЫЧНО НЕ ХУЖЕ подзапроса

(1) скд-профилер? -поделись)

(0) а зачем там вообще соединение ? достаточно же просто запрос к РС.

(0) Конечно, нужно смотреть планы запросов.
С одной стороны использовать inner join для фильтрации как бы неправильно - см. например https://stackoverflow.com/questions/2177346/can-an-inner-join-offer-better-performance-than-exists
https://stackoverflow.com/questions/42249690/what-is-semi-join-in-database
и пр.
Даже если он не размножает записи СУБД может быть сложно об этом догадаться.

С другой стороны INNER JOIN даёт большую свободу планировщику (особенно в случае файлового варианта).
Но правда свобода планировщика это не всегда хорошо.

В общем нужно смотреть планы запросов.

Ни тот ни тот не оптимален

(7) Частично согласен. Первый запрос оптимальнее будет написать так:

ВЫБРАТЬ
    |    Номенклатура.Ссылка
    |ИЗ
    |    Справочник.Номенклатура КАК Номенклатура
    |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
    |                ЗначенияКатегорийНоменклатуры.Номенклатура
    |            ИЗ
    |                РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
    |            ГДЕ
    |                ЗначенияКатегорийНоменклатуры.Категория = &Категория) КАК ЗначенияКатегорийНоменклатуры
    |        ПО Номенклатура.Ссылка = ЗначенияКатегорийНоменклатуры.Номенклатура

А второй как оптимальнее?

(0) С подзапросом хуже - СУБД часто ошибается с планом

И БТВ, а почему не так?

ВЫБРАТЬ
    ЗначенияКатегорийНоменклатуры.Номенклатура
ИЗ
    РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
ГДЕ
    ЗначенияКатегорийНоменклатуры.Категория = &Категория

(10) Не знаю структуры регистра (может наменяли), возможно добавить "РАЗЛИЧНЫЕ", что бы двойников не было:

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ЗначенияКатегорийНоменклатуры.Номенклатура
ИЗ
    РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
ГДЕ
    ЗначенияКатегорийНоменклатуры.Категория = &Категория

(11) А с каких пор соединение с вложенным запросом стало оптимальным?

Если запрос содержит соединения с вложенными запросами, то это может привести к следующим негативным последствиям:
Крайне медленное выполнение запроса при слабой загрузке серверного оборудования. Замедление запроса может быть очень значительным (до нескольких порядков);
Нестабильная работа запроса. При некоторых условиях запрос может работать достаточно быстро, при других - очень медленно;
Значительная разница по времени выполнения запроса на разных СУБД;
Повышенная чувствительность запроса к актуальности и полноте статистик. Сразу после полного обновления статистик запрос может работать быстро, но через некоторое время опять замедлиться.

https://its.1c.ru/db/v8std/content/655/hdoc

(10) Но в (0) написано что пример утрирован. Суть не в том как в конкретном данном случае. А в принципе какая конструкция работает быстрее.

(11) ну судя по названию РС, там дублей быть не может

(13) >> Но в (0) написано что пример утрирован.

Точно)))

(12) Чем так вложенный запрос пугает?
Оптимальнее в том, что что вторая присоединяемая таблица может быть на порядок меньше и это уже может дать существенный прирост производительности. Зависит от данных.

(16) очень зависит от статистики, которая к тому же меняется во времени

(16) понятно, что если размер будет небольшой, то это быстро отработает.

Если убрать условие на категорию, тогда подзапрос не нужен - и даже будет вреден.