|
Какой запрос оптимальней? | ☑ | ||
---|---|---|---|---|
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
|
Если убрать условие на категорию, тогда подзапрос не нужен - и даже будет вреден.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |