|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Друзья, здравствуйте! Давно не занимался вопросом. скажите а сейчас есть смысл использовать временные таблицы вместо where in? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 12:59 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale, where in (select id from temp_table) vs join temp_table tt on tt.id = ... ? Или in (1,2,3, ... 100500)? Так это - плохая идея в общем случае, где-то недавно обсуждали. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 13:13 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
crutchmaster Grayscale, where in (select id from temp_table) vs join temp_table tt on tt.id = ... ? Или in (1,2,3, ... 100500)? Так это - плохая идея в общем случае, где-то недавно обсуждали. in (1,2,3, ... 100500) А есть какие-нить пруфы? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 13:19 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Glory! Вернись и помоги. плз! ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:17 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale А есть какие-нить пруфы? помнится раньше Siebel такими конструкциями пользовался при кол-ве значений на 3-5 листов А4 (образно), сиквел выдавал unable to generate execution plan ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:23 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale Давно не занимался вопросом. скажите а сейчас есть смысл использовать временные таблицы вместо where in? Синтаксический анализатор запарится анализировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:09 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
У времянки есть важное преимущество - важных полей может быть много. И ее можно вызывать во многих кусках кода. А в IN еще нужно уметь правильно записать. А если, к примеру, ключи бинарные ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 20:51 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Спасибо, уже кое что) А с точки зрения производительности есть риски какие-нибудь? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 23:26 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale Спасибо, уже кое что) А с точки зрения производительности есть риски какие-нибудь? конечно есть. представьте себе следующую картину: распределение строк этак: colrows1102507810010000000555999 Код: sql 1. 2. 3.
использую гистограмму статистики оптимизатор выстроит план в index seek Код: sql 1. 2. 3.
а вот в этом случае для оптимизатора уже будут некоторые неочевидные вещи. я кстати не уверен что в таком варианте вообще используются range high key из гистограммы темповой таблицы. корреляция значений является неявной, при этом при достаточно объемной темповой таблицей и неравномерном распределении оно вообще дает аккурат приблизительное распределение. в случае с IN (N..., 100, N...) оптимизатор будет понимать что в выборку попадает ключ по которому выбирается овердофига строк и менять план запроса,а вот с временной таблицей такого может и не происходить. надо протестить кстати что будет если к примеру темповая таблица будет содержать 10 строк каких то мелких ключей которые будут в общем случае при соединении таблиц давать мало строк. и будет ли меняться план в случае когда в темповой таблице будет достаточно много строк что бы распределение по гистограмме превышало порог в 200 шагов и темповая таблица содержала ключ 100 но его не присутствовало бы в range high key ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 02:11 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
автора вот в этом случае для оптимизатора уже будут некоторые неочевидные вещи.Конструкция where .. in (select ) сама по себе не очень оптимальна. Правильнее использовать обычное объединение или EXISTS() ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2020, 11:39 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
felix_ff, Спасибо! С Ваших слов получается что where in (1..n) оптимальнее? А сверху в сообщениях говорят, что авторИли in (1,2,3, ... 100500)? Так это - плохая идея в общем случае, где-то недавно обсуждали. авторесли в in будет очень много. Синтаксический анализатор запарится анализировать. И тут мне конечно интереснее про общий случай. Понятно что огромный объемпараметров вызовет нагрузку на анализатор и она не буде отражена в плане. Но вот какие еще есть ограничения? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2020, 15:14 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale felix_ff, Спасибо! С Ваших слов получается что where in (1..n) оптимальнее? Да, в случае когда у Вас не овер 100500 констант в IN Я точно не помню порог но вроде когда значений приближается к 50 тысячам начинают вылазить "артефакты оптимизатора" вплоть до ошибки 8623. опять таки в случае с временными таблицами вы выигрываете в плане скорости компиляции запроса, но можете проиграть в оценках кол-ва строк и соответственно в результирующем плане. Но обычно такие ситуации разруливаются детально вручную. Вы можете везде использовать времянку как источник предиката, но в случае когда вы явно видите что конкретный запрос тормозит - тюнить конкретный запрос исходя из значений времянки. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2020, 17:02 |
|
Where in vs temp table
|
|||
---|---|---|---|
#18+
Grayscale, При больших списках будете просто проигрывать на компиляции, причем существенно Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2020, 18:04 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1685325]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
9ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 293ms |
total: | 447ms |
0 / 0 |