Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Help with INNER JOIN

Former Member
0 Likes
1,396

Hi All,

The following statement takes quite a long time to run. Any suggestions how it can be fine tuned.

SELECT MSEGWERKS MSEGBWART MKPFBUDAT MKPFBLDAT

MKPFBKTXT MKPFMBLNR MSEGGRUND MSEGLGORT

MSEGMATNR MSEGMENGE MSEGUMLGO MSEGSGTXT

MSEGCHARG T156TBTEXT T001WSPRAS MSEGCHARG

MSEGSHKZG MKPFCPUTM

INTO TABLE T_OUTPUT

FROM MKPF

INNER JOIN MSEG

ON MKPFMBLNR = MSEGMBLNR

AND MKPFMJAHR = MSEGMJAHR

INNER JOIN T001W

ON MSEGWERKS = T001WWERKS

INNER JOIN T156T

ON MSEGBWART = T156TBWART

AND MSEGSOBKZ = T156TSOBKZ

AND MSEGKZBEW = T156TKZBEW

AND MSEGKZZUG = T156TKZZUG

AND MSEGKZVBR = T156TKZVBR

WHERE MKPF~BUDAT IN S_BUDAT

AND MSEG~WERKS EQ P_WERKS

AND MSEG~XAUTO NE 'X'

AND MSEG~BWART IN S_BWART

AND MSEG~MATNR IN S_MATNR

AND T156T~SPRAS EQ SY-LANGU.

Regards

Brain

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,027

Have you tried to run SQL trace for your program to see why this select takes so long ?

I would rather select from MKPF & MSEG via join and then select other data from t001w & T156T. In this case you can put some logic to access T001w & T156T just to retrieve data for already selected plants/movement types.

Besides, it really helps optimizer to chose right access path if you keep your select statements simple

5 REPLIES 5
Read only

Former Member
0 Likes
1,027

You can start by making sure that S_MATNR is not empty.

You might also try some re-arranging:

SELECT mseg~werks mseg~bwart mkpf~budat mkpf~bldat
         mkpf~bktxt mkpf~mblnr mseg~grund mseg~lgort
         mseg~matnr mseg~menge mseg~umlgo mseg~sgtxt
         mseg~charg t156t~btext t001w~spras mseg~charg
         mseg~shkzg mkpf~cputm
    INTO TABLE t_output

    FROM mseg
    INNER JOIN mkpf
       ON mkpf~mblnr = mseg~mblnr
      AND mkpf~mjahr = mseg~mjahr
    INNER JOIN t001w
       ON t001w~werks = mseg~werks
    INNER JOIN t156t
       ON  t156t~bwart = mseg~bwart
       AND t156t~sobkz = mseg~sobkz
       AND t156t~kzbew = mseg~kzbew
       AND t156t~kzzug = mseg~kzzug
       AND t156t~kzvbr = mseg~kzvbr
    WHERE mseg~matnr IN s_matnr
      AND mseg~werks EQ p_werks
      AND mseg~xauto NE 'X'
      AND mseg~bwart IN s_bwart
      AND mkpf~budat IN s_budat
      AND t156t~spras EQ sy-langu.

Rob

Message was edited by: Rob Burbank

Read only

0 Likes
1,027

Thanks for the response.

However usually S_MATNR is not given.

So basically the plant and the Date are the only parameters given.

Rgarding the splitting up of the inner join, i ll give it a shot.

Any other suggestions....

Regards

Brain

Read only

0 Likes
1,027

Then you will not be able to use an index and it will be slow.

Rob

Read only

0 Likes
1,027

I think there is an index on BUDAT in MKPF.

Would be great if this select with join uses this index.

That is why I think it would be easier for optimizer to select right path if join is limited to MKPF/MSEG only.

OR if even MKPF/MSEG join does not use index - select from MKPF into internal table, then select from MSEG/T001W/T... using join if necessary, as this join will be by primary keys.

Read only

Former Member
0 Likes
1,028

Have you tried to run SQL trace for your program to see why this select takes so long ?

I would rather select from MKPF & MSEG via join and then select other data from t001w & T156T. In this case you can put some logic to access T001w & T156T just to retrieve data for already selected plants/movement types.

Besides, it really helps optimizer to chose right access path if you keep your select statements simple