Текущее время: Ср, июл 23 2025, 15:34

Часовой пояс: UTC + 3 часа


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


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
 Заголовок сообщения: inner join
СообщениеДобавлено: Ср, окт 15 2008, 16:27 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
Есть таблицы для простоты назовем 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'.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, окт 15 2008, 19:25 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
IMHO будет быстрее, если cc_prod_nr - это ключевое поле в Table1. :?

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, окт 16 2008, 15:35 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Если у поля VHCEX в table2 малая селективность (мало возможных значений), то выигрыша не получится - оптимизатор БД нормально работает в таких случаях.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, окт 17 2008, 10:31 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
У VHCEX селективность примерно такая же как и у PRDNO, (думаю что около 40 тыс различных значений)
cc_prod_nr в table 1 не ключевое и индекса с ним не существует


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 27 2008, 17:07 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
В общем проверил на практике
простой выбор из table2 занял
1.884.185 каких-то там единиц времени (по-моему микросекунд, но я не уверен, а лезть сейчас в доку лень)
выбор с помощью приведенной выше конструкции занял
108.602 этих же единиц времени


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 27 2008, 19:03 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
На всякий случай хочу заметить, что для чистоты эксперимента надо проводить как минимум по 3 независимых прогона каждого варианта. Если просто прогнать вариант 1, а потом вариант 2 (который, в сущности, использует те же данные), то при 2-м тесте данные уже будут выбираться из буфера (или что-то в этом роде), что работает гораздо быстрее. Сама пару раз на это напарывалась. :(

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 27 2008, 19:17 
Модератор
Модератор
Аватара пользователя

Зарегистрирован:
Пт, июн 16 2006, 00:43
Сообщения: 1686
Откуда: Москва <-> Красноярск
Пол: Мужской
Цитата:
If a join expression is used, the SELECT command circumvents SAP buffering
(c) SAP

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, окт 28 2008, 13:04 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
Сегодня тест повторил запрос с join, без осуществеления других запросов. Результат 196.864 микросекунд


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, окт 30 2008, 12:22 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, мар 02 2005, 20:19
Сообщения: 133
Откуда: Moscow
А еще быстрее будет, если вместо INTO CORRESPONDING FIELDS OF TABLE использовать INTO TABLE (при условии, что порядок полей будет соблюден)

_________________
Монарх - это серъезно (с) "Классик"


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, окт 30 2008, 18:45 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
это да, согласен,
обнаружил еще такой эффект интересный
напомню Ключ 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 сек. Как думаете, в чем может быть причина, в оптимизаторе БД?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, окт 30 2008, 19:08 
Гуру-эксперт
Гуру-эксперт

Зарегистрирован:
Вт, сен 07 2004, 17:47
Сообщения: 2988
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 пустая то это значит что условие с его участием всегда верно и, возможно, тогда оно просто выкидывается из формируемого запроса. Ну а потом уже исходя из тех реальных запросов думать насчёт оптимизатора базы.

_________________
"После" - не значит "вследствие"


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, окт 31 2008, 10:52 
Модератор
Модератор
Аватара пользователя

Зарегистрирован:
Пт, июн 16 2006, 00:43
Сообщения: 1686
Откуда: Москва <-> Красноярск
Пол: Мужской
Планы запросов смотрите.
Поскольку без них сложно говорить предметно.
Я вот подозреваю, что на таблице2 есть вторичные индексы и что поле rpnam обладает малой селективностью. Ну и что
Code:
ON   v~vhcex      = z~vhcex
AND v~cc_prod_nr = z~prodno

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

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, окт 31 2008, 13:13 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Чт, окт 26 2006, 15:07
Сообщения: 227
БД ORACLE.
А что означает "планы запросов"? У меня просто всё на английском и в ST05 я не очень силен :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, окт 31 2008, 14:00 
Модератор
Модератор
Аватара пользователя

Зарегистрирован:
Пт, июн 16 2006, 00:43
Сообщения: 1686
Откуда: Москва <-> Красноярск
Пол: Мужской
План запроса смотрится так:
В ST05 открываем SQL лог.
И в нем выбираем запрос и жмем explain.
Собственно в плане запроса видно какие индыксы были использованы и как происходило объединение таблиц.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, окт 31 2008, 19:28 
Президент
Президент

Зарегистрирован:
Пт, апр 28 2006, 22:39
Сообщения: 2514
Откуда: North Taxolina, USA
Пол: Женский
matel написал(а):
А что означает "планы запросов"? У меня просто всё на английском и в ST05 я не очень силен :)


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

_________________
"One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important." Bertrand Russell


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

Часовой пояс: UTC + 3 часа


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

Сейчас этот форум просматривают: Google [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB