inner join нескольких таблиц, порядок обработки

yes

Коллеги, помогите разобраться. В наследство достался такой код.

SELECT * INTO ...
FROM tab1
INNER JOIN tab2 ON tab2~field = tab1~field
tab2~ ... = tab1~
INNER JOIN tab3 ON tab3~field = tab1~field
WHERE
tab1~field1 = Константа and
tab1~field2 =...

Есть индексы в всех полях соответствующих таблиц

В результе трассировки выяснилось работает так:
1. TABLE ACCESS FULL в таблице tab2
2. TABLE ACCESS FULL в таблице tab3
3. Далее JOIN tab2 и tab3
4. Выбор из tab1 по индексу и JOIN.

Соответственно работает медленно. Предполагалось первой пойдет выборка из tab1.
Есть идеи как побороть ситуацию без разбиения с for all entries?

Пономарев Артем

Какая субд?
Сколько записей в таблице1, таблице2 и таблице3?
Какой джойн между таблицей2 и таблицей3? (HASH, MERGE)

Приведите полные условия соединений всех таблиц.
Приведите полные списки полей в индексах.

yes

Какая субд?
Оракл

Сколько записей в таблице1, таблице2 и таблице3?
tab1 - 578 969
tab2 - 224 925
tab3 - 810 521

Какой джойн между таблицей2 и таблицей3? (HASH, MERGE)
hash

Приведите полные условия соединений всех таблиц.
SELECT DISTINCT *
INTO ...
FROM tab1
INNER JOIN tab2 ON tab2~trdoc = tab1~trdoc
INNER JOIN tab3 ON tab3~trdoc = tab1~trdoc
AND tab3~vrsio = tab1~vrsio
WHERE tab1~rfcdest = Constanta
AND ( ( tab1~send_status IN ('E', 'S', 'W', '') ) OR ( tab1~answer_status IN ('E', 'W', '') ) ) .

Приведите полные списки полей в индексах
.
tab1:
-Первичный ключ (trdoc, vrsio)
-Индекс(rfcdest+send_status+answer_status )

tab2:
-Первичный ключ (trdoc)

tab3:
-Индекс(trdoc,vrsio,trpos)

Пономарев Артем

Весьма странное повдение для таких исходных данных.

Рекомендую пересобрать статистику по всем таблицам (или попросить об этом базис).

yes

уже прогоняли статистику, ничего не изменилось(

Rokhay

Выглядит так, будто БД индексов не видит.
Точно ли индексы активны и существуют для вашей БД?

Пономарев Артем

Rokhay написал:

Выглядит так, будто БД индексов не видит.
Точно ли индексы активны и существуют для вашей БД?

Судя по предоставленным данным FULL SCANа для таблицы 2 быть все равно не должно.
Даже в случае отсутвия вторичных индексов на таблицу1 и таблицу3.
Хотя есть вероятность что оптимизатор считает более продуктивным построением HASH таблицы по таблице2.

Присоединяюсь к Rokhay:
проверьте что все индексы активны и созданы как Index in all database systems.

Удав

Скорее всего оптимизатор решил, что ограничение по полям tab1 мало влияет на результат выборки из этой таблицы и поэтому берет основной таблицей для выборки tab2, в которой меньше всего записей.
Кстати, индекс на tab1 rfcdest, send_status, answer_status лучше разбить на 2: rfcdest, send_status и rfcdest, answer_status

И сделать хотя бы еще одно ограничение, например по датам.

Пономарев Артем

Удав написал(а):

Скорее всего оптимизатор решил, что ограничение по полям tab1 мало влияет на результат выборки из этой таблицы и поэтому берет основной таблицей для выборки tab2, в которой меньше всего записей.

Скорее всего да, селективность малая. Но даже в таком случае( FULL SCAN по таблице2 с построением HASHа ) обращение к таблице3 должно идти по индексу, а никак не полным перебором.

Цитата:

Кстати, индекс на tab1 rfcdest, send_status, answer_status лучше разбить на 2: rfcdest, send_status и rfcdest, answer_status

ИМХО, очень спорно.
Я бы скорее посоветовал включить в индекс trdoc, vrsio. Иначе получаем хоть и малозатратную операцию доступа к строке по индексу, но все же.

yes

все индексы существуют во всех БД и активны

Прогон статистики в системе разработки (небольшое количество) дает положительный результат, выборка идет из tab1 как и задумано
Прогон статистики в продуктиве (количество описано выше) не помогает, идет полная выборка из tab2 и tab3

Пономарев Артем

yes, а в таблице 1 в продуктиве сколько записей, для которых выполняется условие

Code:

tab1~rfcdest = Constanta
AND ( ( tab1~send_status IN ('E', 'S', 'W', '') ) OR ( tab1~answer_status IN ('E', 'W', '') ) ) .

?

Ну и таки попробуйте засунуть в индекс trdoc и vrsio для таблицы1 с прогоном статистики.

yes

[quote="Пономарев Артем"]yes, а в таблице 1 в продуктиве сколько записей, для которых выполняется условие

Code:

tab1~rfcdest = Constanta
AND ( ( tab1~send_status IN ('E', 'S', 'W', '') ) OR ( tab1~answer_status IN ('E', 'W', '') ) ) .

?

~34 000

Пономарев Артем

yes,
поведение вашего продуктива аномально.
Должен смотрть базис.
Возможно неверно настроены параметры, затрагивающие оптимизатор.
Вы же пока можете приписать:

Code:

%_HINTS ORACLE 'INDEX ( "таблица1" "таблица1~индекс")'.

Удав

Пономарев Артем написал:

Удав написал(а):

Кстати, индекс на tab1 rfcdest, send_status, answer_status лучше разбить на 2: rfcdest, send_status и rfcdest, answer_status

:shock:
ИМХО, очень спорно.
Я бы скорее посоветовал включить в индекс trdoc, vrsio. Иначе получаем хоть и малозатратную операцию доступа к строке по индексу, но все же.

Да ну

Code:

  SELECT COUNT( * ) INTO trfc_count
      FROM arfcsstate
      WHERE ( arfcfnam = 'IDOC_INBOUND_ASYNCHRONOUS'
        OR  arfcfnam = 'INBOUND_IDOC_PROCESS' )
      AND arfcreserv LIKE mfeld.

А вот план выполнения для этого запроса:

Code:

SELECT STATEMENT                                                    
                                                                    
    5  6 SORT AGGREGATE                                             
                                                                    
        5  5 CONCATENATION                                          
                                                                    
            5  2 TABLE ACCESS BY INDEX ROWID ARFCSSTATE             
                                                                    
                   1 INDEX RANGE SCAN ARFCSSTATE~03                 
                     Search Columns: 1                              
                                                                    
            5  4 TABLE ACCESS BY INDEX ROWID ARFCSSTATE             
                                                                    
                   3 INDEX RANGE SCAN ARFCSSTATE~03                 
                     Search Columns: 1                              

Оптимизатор ORACLE в данном случае разбивает SQL на 2 подзапроса и в каждом из них пытается выбрать индекс.

Удав

Пономарев Артем написал:

yes,
поведение вашего продуктива аномально.
Должен смотрть базис.
Возможно неверно настроены параметры, затрагивающие оптимизатор.
Вы же пока можете приписать:

Code:

%_HINTS ORACLE 'INDEX ( "таблица1" "таблица1~индекс")'.

Подробнее про хинты Oracle можно посмотреть в ноте 130480

Правила форума

inner join нескольких таблиц, порядок обработки

Кто сейчас на конференции