Вход | Регистрация
 

Какой запрос оптимальней?

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

Например :

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

ИЛИ

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

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

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

В общем нужно смотреть планы запросов.
   ViSo76
 
7 - 14.12.20 - 21:09
Ни тот ни тот не оптимален
   Said_We
 
8 - 16.12.20 - 12:34
(7) Частично согласен. Первый запрос оптимальнее будет написать так:

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

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

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

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

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

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

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

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.