|
соединение таблиц и условие ГДЕ | ☑ | ||
---|---|---|---|---|
0
qeos
17.05.17
✎
10:51
|
Возник тут у нас спор с коллегами на такую тему:
Я утверждал что условия в секции ГДЕ накладываются на результат соединения таблиц. Т.е. сначала таблицы соединяются левым или любым другим соединением, а уже на результат соединения накладывается условие. Однако коллега утверждал иное и продемонстрировал это на примере: ВЫБРАТЬ Т1.Рес1, Т2.Рес1 ИЗ РегистрСведений.хх КАК Т1 ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.хх КАК Т2 ПО Т1.Изм1 = Т2.Изм1 И Т1.Изм2 = т2.Изм2 ГДЕ Т2.Изм2 = "блабла" в результате выполнения запроса профайлер показал что план запросов был такой: две выборки с index seek с отбором P1 = "блабла" и соединение nested loops этих двух таблиц и вот получается что он прав. но возможно, это частный случай? если сравнивать с null Т2.Рес1, то мы видим обратную картину, т.е. сначала соединение таблиц, и уже в конце фильтр по null. кто из нас прав-то? меня учили что ГДЕ накладывается на результат соединений... |
|||
1
Господин ПЖ
17.05.17
✎
10:53
|
>но возможно, это частный случай?
это общий. п.э. все пихают "где" в условия соединения |
|||
2
qeos
17.05.17
✎
10:55
|
(1) "п.э." это что?
|
|||
3
Господин ПЖ
17.05.17
✎
10:57
|
полиэстр
|
|||
4
qeos
17.05.17
✎
11:00
|
О_о
|
|||
5
qeos
17.05.17
✎
11:02
|
т.е. например сумма тоже пихнется в условия соединения?
ГДЕ Т1.Рес1 + Т2.Рес1 = 0 |
|||
6
Одинесю
17.05.17
✎
11:22
|
(2) поэтому
|
|||
7
SanGvin
17.05.17
✎
11:25
|
так отработало потому что соединение на равенство по полю отбора стоит.
|
|||
8
AquaMan
17.05.17
✎
11:29
|
В SQL запросе ГДЕ выполняется после соединения. Тут или 1С при трансляции изменило запрос, или оптимизатор догадался.
|
|||
9
Vaflya
17.05.17
✎
11:31
|
где выполняется после соединения, на результат
|
|||
10
Vaflya
17.05.17
✎
11:32
|
*накладывается на результат
|
|||
11
ptiz
17.05.17
✎
11:56
|
(0) "а уже на результат соединения накладывается условие." - с т.зр. логики - всё так, но с т.зр. оптимизатора sql - почему бы и раньше не наложить условие для ускорения.
|
|||
12
zvial
17.05.17
✎
13:54
|
(11) Да, именно тот случай
|
|||
13
Лефмихалыч
17.05.17
✎
14:38
|
(0) Неправы оба. Просто в данном случае СУБД построила запрос именно так. В другом случае она может выбрать другой план запроса, если, например, отбор "P1 = "блабла"" не будет иметь достаточной селективности.
Прав из вас двоих был бы тот, кто сказал, что в результате такого запроса ты всегда получишь внутреннее соединение. А уж как именно СУБД его получит, - зависит от СУБД и конкретной ситуации. |
|||
14
Лефмихалыч
17.05.17
✎
14:40
|
но сознательно вот так (0) для получения внутреннего соединения делают только польностью оформленные законченные мудаки.
Потому что это грабли для сопровождения - легко можно не заметить этой подковырки и долго не понимать, что происходит. |
|||
15
Fragster
гуру
17.05.17
✎
14:44
|
если физический порядок выполнения не влияет на результат, то оптимизатор может переставлять операторы как угодно. в (0) вообще внутреннее соединение и какой-нибудь мерж/хэшмач может быть.
|
|||
16
Лефмихалыч
17.05.17
✎
14:46
|
(0) посмотри, что будет с планом запроса, если Т2.Изм2 будет булево и не индексировано, например
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |