Господа опытные абаперы.
Посмотрите плиз на этот селект и скажите ваше мнение по поводу его оптимизации.
SELECT mara~mtart mseg~matnr makt~maktx mseg~lifnr
mseg~charg ekko~bedat mseg~ebeln mseg~ebelp
ekpo~menge ekpo~meins ekpo~konnr ekpo~ktmng lfa1~adrnr
INTO TABLE lt_sel_data
FROM mseg
JOIN mara ON mara~matnr = mseg~matnr
JOIN ekko ON ekko~ebeln = mseg~ebeln
JOIN ekpo ON ekpo~ebeln = mseg~ebeln AND
ekpo~ebelp = mseg~ebelp
JOIN lfa1 ON lfa1~lifnr = mseg~lifnr
JOIN makt ON makt~matnr = mseg~matnr AND
makt~spras = sy-langu
WHERE mseg~matnr IN s_matnr
AND mseg~werks IN s_werks
AND mseg~lgort IN s_lgort
AND mseg~smbln = ' '
AND mseg~lifnr IN s_lifnr
AND mseg~charg IN s_charg
AND mara~mtart IN s_mtart
AND mara~matkl IN s_matkl
AND ekko~ekorg IN s_ekorg
AND ekko~ekgrp IN s_ekgrp
AND ekko~ebeln IN s_ebeln
AND ekko~bedat IN s_bedat
AND NOT EXISTS ( SELECT * FROM *mseg
WHERE smbln = mseg~mblnr
AND sjahr = mseg~mjahr
AND smblp = mseg~zeile )
ORDER BY mara~mtart mseg~matnr mseg~lifnr mseg~charg
ekko~bedat mseg~ebeln mseg~ebelp.

Ну да, заджойнено много, но ведь по ключу - на мой взгляд, все быстрее, чем потом в цикле по внутренней таблице делать select single (или что-то еще такого плана, типа for all entries всякие).
Условия под where вроде тоже перечислены в правильном порядке.

При условии, что все указанные ограничения по перечисленным полям и таблицам должны иметь место - ваше мнение, нужно и можно ли его оптимизировать и как?
/на то, что MAKT джойнится не по LEFT JOIN - не совсем хорошо, но пусть пока, не обращайте внимания/

Небольшое уточнение - из MSEG вообще говоря интересует только CHARG, при условии, что lifnr ebeln ebelp не пусты. Но селект-то по-любому нужен какой-то.....

у тебя куча рангов, поэтому непонятно, какой будет план запроса. Надо получить планы запросов (st05) для наиболее часто используемых вариантов вызова запроса. Проанализировать на использование индекса.
для 46С
в exists будет использоваться индекс S
Если в условиях отбора будут материал \ завод \ склад - то будет использоваться индекс M. но это в том случае, если ранги будут относительно небольшими. Может оказаться лучше переписать на for all entries (если указано правильное значение параметра, который определяет построение запроса с for all entries)

повторяю, информации недостаточно

abaper:
Во-первых, нужно опредлиться какие цели ты преследуешь для оптимизации запроса. Не устраивает текущее быстродействие?
Мне, например, не очень нравятся многоэтажные джойны из-за их громоздкости. Но это дело вкуса. Хороший с точки зрения быстродействия результат всегда получается после длительного тюнинга и как минимум 3х-4х вариантов извлечения данных.
Что сразу бросается в глаза - where clause. Если таблицы s_* заполняются через select-options, допускающим многократный выбор, то пользователю пара пустяков ввести такой критерий выборки, который приведет к полному перебору одной из указанных там таблиц.
Коррелированный подзапрос ничего сильно не замедлит, потому как выполнится по вторичному индексу. Ну, и сортировку результирующей выборки лучше выполнить на abap'e. Можно просто объявить lt_sel_data как sorted table.
И потом, проанализируй в среднем количество выбираемых данных, которые будут делать пользователи. Если в результате запроса, как правило, выбирается несколько десятков записей, то такой join отнюдь не оптимальный выбор.

ok