Poor performance reading MBEWH table

Question

Hi,
I'm getting serious performance problems when reading MBEWH table directly.
I did the following tests:
  GET RUN TIME FIELD t1.
  SELECT mara~matnr
    FROM mara
    INNER JOIN mbewh ON mbewh~matnr = mara~matnr
    INTO TABLE gt_mbewh
    WHERE mbewh~lfgja = '2009'.
  GET RUN TIME FIELD t2.
  GET RUN TIME FIELD t3.
  SELECT mbewh~matnr
    FROM mbewh
    INTO TABLE gt_mbewh
    WHERE mbewh~lfgja = '2009'.
  GET RUN TIME FIELD t4.
t2 = t2 - t1.
t4 = t4 - t3.
write: 'With join: ', t2.
write /.
write: 'Without join: ', t4.
And as result I got:
With join:      27.166
Without join:  103970.297
All MATNR in MBEWH are in MARA.
MBEWH has 71.745 records and MARA has 705 records.
I created an index for lfgja field in MBEWH.
Why I have better performance using inner join?
In production client, MBEW has 68 million records, so any selection takes too much time.
Thanks in advance,
Frisoni

Answer 1

Guilherme, Hermann, Siegfried,
I have just seen this thread and read it from top to bottom, and I would say now is a good time to make a summary..
This is want I got from Guilherme's comments:
1) MBEWH has 71.745 records
2) There are two hidden clients in the same server with 50 million rocords.
3) Count Distinct mandt = 6
4) In production client, MBEW has 68 million records
First measurement
With join               : 27.166
Without join            :  103970.297
Second measurement
With join               : 96.217
Without join            : 93.781            << now with hint
The original question was to understand why using the JOIN made the query much faster.
So the conclusions are:
1) Execution times are really now much better (comparing only the not using join case, which is the one we are working on), and the original "mystery" is gone
2) In this client, MANDT is actually much more selective that the optimizer thinks it is (and it's because of this uneven distrubution, as Hermann mentioned, that forcing the index made such a difference)
4) Bad news is that this solution was good because of the special case of your development system, but will probably not help in the production system
5) I suppose the index that Hermann suggested is the best possible thing to do (the table won't be read, assuming you really only want only MATNR from MBEWH, and that it wasn't a simplification for illustration purposes); anyway, noone can really expect that getting all entries from MBEWH for a given year will be a fast thing...
Rui Dantas