|
|
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
hi all Дано: 1) две таблицы (master-detail), в мастере 2000 строк, в детали - по 500 строк на каждую мастер-строку. 2) мастер-таблица имеет два доп. идексированных поля: optype_id и state_id, число уник. значений в них = 10 и 3 соотв-но, сами значения распределены равномерно 3) после заполнения тестовыми данными выполнен пересчет статистики по индексам: Код: 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. 30. 31. 32. 33. 34. Задача: подсчитать число записей в детали (d), для которых выполнено следующее условие в мастере (h): h.optype_id = 5 and h.state_id in (2,3) - для соотв-щего d.doc_id = h.id; плюс еще один доп фильтр на неиндексированные поля, но это уже неважно. Запрос-1 , через inner join . Выполняется мгновенно: Код: 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. Запрос-2 , через exists , с указанием в нём ВСЕХ условий на мастер-таблицу. Выполняется хреново: Код: 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. Причина очевидна: ФБ идёт натуралом по всей детали, т.е. она - ведущая. Что помешало оптимизатору "увидеть" в exists-подзапросе связь по PK-FK и доп. фильтры по полям optype_id & state_id, дабы родить вначале источник данных на основании именно мастера ? Т.е. проще говоря - преобразовать запрос с exists(), когда в его where-условии идёт запрос по PK, к inner join'у - такое будет когда-нить в ФБ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2014, 17:32:32 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Таблоид, когда нибудь будет semi-join 1. NESTED LOOP по индексу (почти как сейчас) 2. HASH 3. MERGE что касается превращения exists в inner join оно может и будет, но там всю производительность может убить сортировка для исключения дубликатов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2014, 17:59:12 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Симонов Денисчто касается превращения exists в inner join оно может и будет, но там всю производительность может убить сортировка для исключения дубликатовНе будет там никаких дубликатов. И б убликатов тоже :-) Ибо: "преобразовать запрос с exists(), когда в его where-условии идёт запрос по PK " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2014, 18:27:12 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Таблоид, а если не PK, а UNQ, то отдельную ветку? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 09:53:22 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Таблоид, не надоело задавать риторические вопросы? Уже неоднократно упоминалось, что констрейнты оптимизатором никак не учитываются. Да, могут. Нет, не сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 10:46:07 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Да ну, лично я двумя руками голосую против всяких оптимизаций типа разворачивания exist-а в джойн по констрейнту. Нафиг-нафиг. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 10:48:36 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, Поддержу. Разруха, она в головах. Наводить порядок нужно в запросе, а не в оптимизаторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 11:42:58 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
WildSeryНаводить порядок нужно в запросе, а не в оптимизаторе.Не ну если по делу, то можно и в оптимизаторе. Гаджимурадов Рустамтипа разворачивания exist-а в джойн по констрейнту. Нафиг-нафиг.Вот этого точно не надо, я и сам соображу где мне джойн врисовать, а где экзисц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 13:22:02 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevsky> Не ну если по делу, то можно и в оптимизаторе. Ivan_Pisarevsky> Вот этого точно не надо, я и сам соображу Ivan_Pisarevsky> где мне джойн врисовать, а где экзисц. У тебя два предложения противоречат друг другу. Вчитайся в них и в топик ещё раз. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 13:30:46 |
|
||
|
Преобразование запроса с EXEISTS( select * from X where <some_cond_on_X_PK> ) к INNER JOIN
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамУ тебя два предложения противоречат друг другу.Да, как-то нескладно. Оптимизатор надо пилить по делу, предложение в заголовке топика к таковым(требующим изменений оптимизатора) не отношу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2014, 14:09:46 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38608388&tid=1563724]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
179ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 500ms |

| 0 / 0 |
