inner join

matel

Есть таблицы для простоты назовем table1 и table2. У table2 около миллиона записей. У table1 40 тыс. .
Ключ table2: MANDT, VHCEX, PRDNO, RPNAM.
Мне надо выбрать данные из table2, но в качестве критерия я знаю только значения PRDNO, RPNAM.
table1 связана с table2 по полям VHCEX, PRDNO, но они ключевыми не являются.
Будет ли такой селект работать быстрее, чем простой выбор из table2.

Code:

 SELECT z~prodno z~rpnam
    FROM  table1 AS v INNER JOIN table2 AS z
      ON   v~vhcex      = z~vhcex
       AND v~cc_prod_nr = z~prodno
    INTO CORRESPONDING FIELDS OF TABLE lt_plaf
    FOR ALL ENTRIES IN lt_plaf
    WHERE v~cc_prod_nr = lt_plaf-prdno
      AND z~rpnam      = lt_plaf-rpnam
      AND z~chkpttyp   = 'A'.

Возможности протестить не имею.

Jelena

IMHO будет быстрее, если cc_prod_nr - это ключевое поле в Table1.

Удав

Если у поля VHCEX в table2 малая селективность (мало возможных значений), то выигрыша не получится - оптимизатор БД нормально работает в таких случаях.

matel

У VHCEX селективность примерно такая же как и у PRDNO, (думаю что около 40 тыс различных значений)
cc_prod_nr в table 1 не ключевое и индекса с ним не существует

matel

В общем проверил на практике
простой выбор из table2 занял
1.884.185 каких-то там единиц времени (по-моему микросекунд, но я не уверен, а лезть сейчас в доку лень)
выбор с помощью приведенной выше конструкции занял
108.602 этих же единиц времени

Jelena

На всякий случай хочу заметить, что для чистоты эксперимента надо проводить как минимум по 3 независимых прогона каждого варианта. Если просто прогнать вариант 1, а потом вариант 2 (который, в сущности, использует те же данные), то при 2-м тесте данные уже будут выбираться из буфера (или что-то в этом роде), что работает гораздо быстрее. Сама пару раз на это напарывалась.

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

Цитата:

If a join expression is used, the SELECT command circumvents SAP buffering

(c) SAP

UPD: Вот буфер БД - это да. Может повлиять.

matel

Сегодня тест повторил запрос с join, без осуществеления других запросов. Результат 196.864 микросекунд

Monarch

А еще быстрее будет, если вместо INTO CORRESPONDING FIELDS OF TABLE использовать INTO TABLE (при условии, что порядок полей будет соблюден)

matel

это да, согласен,
обнаружил еще такой эффект интересный
напомню Ключ table2: MANDT, VHCEX, PRDNO, RPNAM.
и pdate в table2 ключевым не является
если записать так

Code:

SELECT z~prodno z~rpnam 
    FROM  table1 AS v INNER JOIN table2 AS z 
      ON   v~vhcex      = z~vhcex 
       AND v~cc_prod_nr = z~prodno 
    INTO CORRESPONDING FIELDS OF TABLE lt_plaf 
    WHERE z~prodno  in so_prdno 
      AND z~rpnam      in so_rpnam
      and  z~pdate      in so_pdate
      AND z~chkpttyp   = 'A'.

то если so_prdno окажется пустым, а so_rpnam будет содержать значения,
(so_pdate всегда заполнено по умолчанию)
то запрос будет выполняться очень долго (около 5 минут), а если so_rpnam также будет пустым, то запрос выполнится за 10 сек. Как думаете, в чем может быть причина, в оптимизаторе БД?

sy-uname

matel написал(а):

это да, согласен,
обнаружил еще такой эффект интересный
напомню Ключ table2: MANDT, VHCEX, PRDNO, RPNAM.
и pdate в table2 ключевым не является
если записать так

Code:

SELECT z~prodno z~rpnam 
    FROM  table1 AS v INNER JOIN table2 AS z 
      ON   v~vhcex      = z~vhcex 
       AND v~cc_prod_nr = z~prodno 
    INTO CORRESPONDING FIELDS OF TABLE lt_plaf 
    WHERE z~prodno  in so_prdno 
      AND z~rpnam      in so_rpnam
      and  z~pdate      in so_pdate
      AND z~chkpttyp   = 'A'.

то если so_prdno окажется пустым, а so_rpnam будет содержать значения,
(so_pdate всегда заполнено по умолчанию)
то запрос будет выполняться очень долго (около 5 минут), а если so_rpnam также будет пустым, то запрос выполнится за 10 сек. Как думаете, в чем может быть причина, в оптимизаторе БД?

Посмотрите какой запрос генериться в этих случаях: если select-options пустая то это значит что условие с его участием всегда верно и, возможно, тогда оно просто выкидывается из формируемого запроса. Ну а потом уже исходя из тех реальных запросов думать насчёт оптимизатора базы.

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

Планы запросов смотрите.
Поскольку без них сложно говорить предметно.
Я вот подозреваю, что на таблице2 есть вторичные индексы и что поле rpnam обладает малой селективностью. Ну и что

Code:

ON   v~vhcex      = z~vhcex
AND v~cc_prod_nr = z~prodno 

соотносятся не как 1:1.
Но это телепатия.

З.Ы.: Кстати, до сих пор не озвучен вендор СУБД

matel

БД ORACLE.
А что означает "планы запросов"? У меня просто всё на английском и в ST05 я не очень силен

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

План запроса смотрится так:
В ST05 открываем SQL лог.
И в нем выбираем запрос и жмем explain.
Собственно в плане запроса видно какие индыксы были использованы и как происходило объединение таблиц.

Jelena

matel написал(а):

А что означает "планы запросов"? У меня просто всё на английском и в ST05 я не очень силен

Query Plan. Только чтобы его видеть, по-моему, требуется отдельная авторизация, которую не всегда дают девелоперам.

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

inner join

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