|
Разбиение одного запроса с JOIN на несколько
|
|||
---|---|---|---|
#18+
Всем привет! Дана таблица А - не очень большая (в ней есть id и дата) и таблица Б - очень большая, партиционирована по дате и есть индекс по id. Запрос на join A и Б по равенству id считается безумно долго и вываливается с ошибкой про отсутствие ресурсов CPU. Планировщик показывает использование HASH JOIN Когда разбиваешь этот запрос на 10 запросов с фильтром на диапазоны дат, эти 10 запросов прорабатывают за разумное время. и HASH JOIN заменяется на NESTED LOOPS Существует ли какой-то хинт или иной прием, который бы заставил оракл вести себя аналогичным образом без разбиения запроса на 10? Заранее спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2020, 22:41 |
|
Разбиение одного запроса с JOIN на несколько
|
|||
---|---|---|---|
#18+
sergunok, Есть хинт USE_NL, это то что вам надо? SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity FROM orders h ,order_items l WHERE l.order_id = h.order_id; Отсюда: https://docs.oracle.com/cd/B12037_01/server.101/b10752/hintsref.htm#5637 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2020, 04:38 |
|
Разбиение одного запроса с JOIN на несколько
|
|||
---|---|---|---|
#18+
sergunok, Не знаю, читаете ли вы ответы :) Вряд ли заставить nested loop здесь оптимальное решение. Из того что я успел прочитать за 10 минут про разные внутренние реализации джойнов, хэш должен быть быстрее. Но хэш, который строится по ведущей таблице (driving table) должен строиться по меньшей из таблиц (А). Возможно ли, что у вас запрос написан таким образом что таблица Б стала ведущей, и это приводит к построению огромного хэша и нехватки памяти? Если это так, можете ли вы переделать запрос чтобы ведущей стала (А)? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2020, 02:10 |
|
|
start [/forum/topic.php?fid=52&fpage=32&tid=1880715]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 153ms |
0 / 0 |