Можно ли как то оптимизировать запрос:

SELECT b027~lifnr
nach~parnr
ekko~ebeln
ekko~aedat
ekko~ernam
nast~erdat
nast~eruhr
nast~vstat
nast~datvr
nast~uhrvr
v_usr_name~name_text AS ernam_text
lfa1~name1
INTO CORRESPONDING FIELDS OF TABLE gt_record
FROM ekko
JOIN b027 ON b027~lifnr = ekko~lifnr
JOIN nast ON nast~objky = ekko~ebeln
JOIN nach ON nach~knumh = b027~knumh
JOIN v_usr_name ON v_usr_name~bname = ekko~ernam
JOIN lfa1 ON lfa1~lifnr = b027~lifnr
WHERE b027~lifnr IN s_lifnr
AND nast~erdat IN s_erdat
AND ekko~ebeln IN s_ebeln
AND nast~vstat IN r_vstat
AND nast~kschl = 'ZEDI'
AND ekko~ernam IN s_ernam
AND (
nast~vstat = '1'
OR nast~vstat = '0' AND NOT EXISTS ( SELECT * FROM nast WHERE objky = ekko~ebeln AND vstat IN ('1') )
OR nast~vstat = '2' AND NOT EXISTS ( SELECT * FROM nast WHERE objky = ekko~ebeln AND vstat IN ('1', '0') )
)
AND EXISTS ( SELECT * FROM ekpo WHERE ekpo~ebeln = ekko~ebeln AND ekpo~werks IN s_werks ).


В частности смущают две строки "NOT EXISTS ( SELECT * FROM nast" Отработает ли запрос быстрее и с тем же результатом если вместо "*" вставить "vstat" ?

Это ужас какой-то...
nast + ekko+ ekpo (через EXIST) и еще куча таблиц....

раздербанивать надо на части....

Слишком сложно, на мой взгляд. Я бы разбил на выборки попроще.
Не забываем, что при джойне выборка не учитывает буфер.

Первое, что видится, это разные подходы к формированию подмножества ограничений на поле NAST-VSTAT. Далее, подзапрос к EKPO можно приJOIN'ить к запросу к EKKO. Кроме того, сомневаюсь, что поле NAST-OBJKY однозначно соответствует EKKO-EBELN, Если не ошибаюсь, NAST-OBJKY длиннее, т.е., кмк, лучше сделать так:

Плюс ко всему, при JOIN следует как можно более полно описать использованный индекс (первичный, по ключевым полям, или вторичный, заведенный в БД). Как-то так. Коллеги, поправляйте, дополняйте.

Жесть. Особенно EXIST'ы. Переписать все заново, а не оптимизировать.

Как минимум:

заменить на JOIN.


Это мракобесие заменить на выборку всех записей из nast по ключу и анализ на стороне сервера приложений.

Уточните, какие select-options обязательны для заполнения?
А так, запрос вполне имеет право на существование. Нужно только добавить мандант в условие join, ограничение kappl в nast, и проконтролировать план запроса, чтобы он был оптимальным. Но это зависит от обязательных условий выбора. Например, если обязательный только завод, то это очень печально.

Нет, * в EXISTS не влияет на производительность.
Переписывание EXISTS на JOIN скорее всего тоже ничего не даст, также как и разбиение на несколько запросов.
Можно попробовать заменить

на


nast~vstat можно добавить в список выборки и убрать из where, с обработкой на абапе после селекта

Скорее всего да, но возможны варианты. Коротенько здесь. Дальше по ссылкам.
EXISTS, обычно, подталкивает оптимизатор к использованию nested loops. Что не всегда оптимально.


Вот мне кажется это первое и основное, что необходимо сделать.

Вот мне кажется это первое и основное, что необходимо сделать.[/quote]


А зачем получать в ABAP то, что не нужно? Так ведь можно и вообще условие where убрать, а потом в абапе отфильтровать

__Gennady, в крайности впадать, конечно, не стоит. Но я бы с удовольствием посмотрел на план запроса и косты с таким условием:

Есь сильное подозрение что это будет весьма забавное зрелище

А в чем проблема? Заказ же укзан. KAPPL+KSCHL можно еще, а так - ничего ужасного.

В общем то нормальный селект, переносить в абап - самое последнее дело, на то и SQL, чтобы данными ворочать. Если долго выполняется запрос, через st05 анализируете конкретный случай и думаете над индексами, только без фанатизму. В основном всё зависит от конкретных условий select-options.

По поводу 2-х строк, можно их сократить за счет настроечной таблички, где определить предпочтения, типа ZTPRTY_VSTAT:

тогда подзапрос можно примерно такой (за точность синтаксиса не ручаюсь, но смысл понятен):

Если бы предпочтения шли в порядке 0 1 2, то и таблички бы не нужно было.

Parazit, если автор спрашивает как оптимизировать запрос - логично предположить что он уже работает с неудовлетворяющим автора временем выполнения.

Мне вот интересно, кто-нибудь в принципе подумал как будет происходить обработка такого условия СУБД? Что на каждую запись из полученного набора (а тут со 100% гарантией nested loops), VSTAT у которой не 1, будет фулл-скан NAST'а?

Оно зависит, конечно, от данных, статистики, индесков и прочего, что есть в системе автора вопроса. Но шансы на такой план выполнения, который я предположил - весьма высоки.

Откуда возникнет fullscan? Nested loop да, но это нормалный план запроса.

__Gennady, осмелюсь предложить взглянуть на первичный ключ и вторичные индексы таблицы NAST. Что, по вашему, должен подумать оптимизатор относительно использования индексов, когда его просят выбрать записи по OBJKY и VSTAT? Я понимаю что это зависит от конкретной ситуации, но в 99,9% тут может быть всего два варианта:
1. FULLSCAN
2. INDEX SKIP SCAN + TABLE ACCESS BY INDEX ROWID
Оба плана, прямо скажем, не быстрые.

Вариант что у автора добавлен индекс опускаем, т.к. не было бы вопроса. Индекс вполне себе решение, кстати. Но я бы, конкретно в этом случае, выкидывал лишние записи на стороне сервера приложений.