Имя: Пароль:
1C
 
Какой запрос оптимальней?
, ,
0 lanc2233
 
14.12.20
19:06
Подскажите, что лучше с точки зрения производительности : внутреннее соединение или вложенный запрос в условиии?

Например :

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

ИЛИ

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

Пример утрирован, не говорите, что нужно сделать просто выборку из регистра значений категорий :-)
1 ДенисЧ
 
14.12.20
19:09
Зависит от размеров таблиц.

Правильный ответ даст тебе скд-профилер.
2 aka MIK
 
14.12.20
19:14
(0) внутреннее соединение однозначно. Оптимизатору так легче выбрать план запроса
3 Ненавижу 1С
 
гуру
14.12.20
19:49
Соединение ОБЫЧНО НЕ ХУЖЕ подзапроса
4 xXeNoNx
 
14.12.20
20:32
(1) скд-профилер? -поделись)
5 Ёпрст
 
14.12.20
20:50
(0) а зачем там вообще соединение ? достаточно же просто запрос к РС.
6 Noser2020
 
14.12.20
21:04
(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 ViSo76
 
14.12.20
21:09
Ни тот ни тот не оптимален
8 Said_We
 
16.12.20
12:34
(7) Частично согласен. Первый запрос оптимальнее будет написать так:

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

А второй как оптимальнее?
9 rphosts
 
16.12.20
12:37
(0) С подзапросом хуже - СУБД часто ошибается с планом
10 Малыш Джон
 
16.12.20
12:39
И БТВ, а почему не так?

ВЫБРАТЬ
    ЗначенияКатегорийНоменклатуры.Номенклатура
ИЗ
    РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
ГДЕ
    ЗначенияКатегорийНоменклатуры.Категория = &Категория
11 Said_We
 
16.12.20
12:41
(10) Не знаю структуры регистра (может наменяли), возможно добавить "РАЗЛИЧНЫЕ", что бы двойников не было:

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ЗначенияКатегорийНоменклатуры.Номенклатура
ИЗ
    РегистрСведений.ЗначенияКатегорийНоменклатуры КАК ЗначенияКатегорийНоменклатуры
ГДЕ
    ЗначенияКатегорийНоменклатуры.Категория = &Категория
12 Малыш Джон
 
16.12.20
12:41
(11) А с каких пор соединение с вложенным запросом стало оптимальным?

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

https://its.1c.ru/db/v8std/content/655/hdoc
13 Said_We
 
16.12.20
12:42
(10) Но в (0) написано что пример утрирован. Суть не в том как в конкретном данном случае. А в принципе какая конструкция работает быстрее.
14 Малыш Джон
 
16.12.20
12:42
(11) ну судя по названию РС, там дублей быть не может
15 Малыш Джон
 
16.12.20
12:44
(13) >> Но в (0) написано что пример утрирован.

Точно)))
16 Said_We
 
16.12.20
12:45
(12) Чем так вложенный запрос пугает?
Оптимальнее в том, что что вторая присоединяемая таблица может быть на порядок меньше и это уже может дать существенный прирост производительности. Зависит от данных.
17 Малыш Джон
 
16.12.20
12:46
(16) очень зависит от статистики, которая к тому же меняется во времени
18 Малыш Джон
 
16.12.20
12:47
(16) понятно, что если размер будет небольшой, то это быстро отработает.
19 Said_We
 
16.12.20
12:54
Если убрать условие на категорию, тогда подзапрос не нужен - и даже будет вреден.
Есть два вида языков, одни постоянно ругают, а вторыми никто не пользуется.