3

内部テーブルには大量のデータが含まれています。

次のコードがあります。

LOOP AT lt_tab INTO ls_tab
  WHERE value1 EQ lv_id1
    AND value2 LE lv_id2
    AND value3 GE lv_id3.

  IF ls_tab-value4 IS NOT INITIAL.
    IF ls_tab-value4 NE lv_var.
      lv_flag = lc_var.
      EXIT.
    ENDIF.
  ELSE.
    lv_flag = lc_var.
    EXIT.
  ENDIF.
ENDLOOP.

データベース テーブルには 7 つのフィールドが含まれ、内部テーブルにはデータベース テーブルと同じ型があります。

where 句には、主キー フィールドはありません。

テーブルには、2 つの主キーで構成される複合キーがあります。テーブル フィールドは、transid(主キー)、item1(主キー)、、、value1およびです。value2value3value4

これらの条件のみに基づいてテーブルを検索する必要があります。しかし、これには時間がかかりすぎます。それを最適化する方法は？

4

6 に答える 6

2

実際の問題が何であるかを完全に確認するために十分な情報を提供していませんが、ループの条件で非キー フィールドを使用しているため、パフォーマンスの問題が発生していると推測できます。

LOOP AT lt_tab INTO ls_tab
  WHERE value1 EQ lv_id1
    AND value2 LE lv_id2 
    AND value3 GE lv_id3.

フィールド、およびを含む変数のテーブル タイプのセカンダリ ソート キーを定義できます。lt_tabvalue1value2value3

次の例を見てください。

REPORT zzy.

CLASS lcl_main DEFINITION FINAL CREATE PRIVATE.
  PUBLIC SECTION.
    CLASS-METHODS:
      class_constructor,
      main.
  PRIVATE SECTION.
    TYPES: BEGIN OF t_record,
      transid TYPE sy-index,
      item1   TYPE char20,
      value1  TYPE p LENGTH 7 DECIMALS 2,
      value2  TYPE p LENGTH 7 DECIMALS 2,
      value3  TYPE p LENGTH 7 DECIMALS 2,
      value4  TYPE p LENGTH 7 DECIMALS 2,
    END OF t_record,
    tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1.
*    tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1
*          WITH UNIQUE SORTED KEY sec_key COMPONENTS value1 value2 value3.
    CONSTANTS:
      mc_value1 TYPE p LENGTH 7 DECIMALS 2 VALUE '100.00',
      mc_value2 TYPE p LENGTH 7 DECIMALS 2 VALUE '150.00',
      mc_value3 TYPE p LENGTH 7 DECIMALS 2 VALUE '10.0'.
    CLASS-DATA:
      mt_record TYPE tt_record.
ENDCLASS.

CLASS lcl_main IMPLEMENTATION.
  METHOD class_constructor.
    DO 2000000 TIMES.
      INSERT VALUE t_record( transid = sy-index item1 = |Item{ sy-index }| 
            value1 = sy-index value2 = sy-index / 2 value3 = sy-index / 4 value4 = 0 )
        INTO TABLE mt_record.
    ENDDO.
  ENDMETHOD.

  METHOD main.
    DATA:
      l_start TYPE timestampl,
      l_end   TYPE timestampl,
      l_diff  LIKE l_start.
    GET TIME STAMP FIELD l_start.
    LOOP AT mt_record INTO DATA(ls_record) "USING KEY sec_key
      WHERE value1 = mc_value1 AND value2 >= mc_value2 AND value3 <= mc_value3.

      ASSERT 1 = 1.

    ENDLOOP.
    GET TIME STAMP FIELD l_end.
    l_diff = l_end - l_start.

    WRITE: / l_diff.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
  lcl_main=>main( ).

テーブルタイプtt_recordが次のように定義されている場合

tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1.

0.156次に、SAP システムでのループの実行時間は秒単位で異なります0.266。

ただし、次のように定義すると

tt_record TYPE STANDARD TABLE OF t_record WITH NON-UNIQUE KEY transid item1
      WITH UNIQUE SORTED KEY sec_key COMPONENTS value1 value2 value3.

ヒントを追加してループを調整すると、USING KEY sec_key毎回取得する実行時間は0.00.

于 2016-05-03T14:47:59.533 に答える
0

大量のデータがある場合、コード行を少し高速化しても役に立ちません。

問題はおそらく、テーブル全体のスキャンを行っていることです。テーブルの各行を処理しています (探しているものが見つかるまで)

このタイプの問題には、ソートされたテーブルとハッシュされたテーブルがあります。

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb366d358411d1829f0000e829fbfe/content.htm

それらを賢く使用すると、選択はテーブル内の行の一部のみをチェックする必要があり、テーブル内のデータの分布に応じて、選択が非常に高速になります。

于 2016-05-13T08:02:28.207 に答える