performance - ABAPはパフォーマンスのヒントを選択しますか？

Question

Big Queryのパフォーマンスに関連する一般的なABAP固有のヒントはありますか？SELECT

FOR ALL ENTRIES IN特に、 vsのすべての質問を一度に閉じることは可能JOINですか？

Answer 1

いくつかの (多かれ少なかれ) ABAP 固有のヒント:

SELECT * が不要な場合は避け、必要なフィールドのみを選択するようにしてください。理由: プロセス中にすべての値が数回マップされる可能性があります (DB ディスク --> DB メモリ --> ネットワーク --> DB ドライバ --> ABAP 内部)。とにかくフィールドが必要ない場合は、CPU サイクルを節約するのは簡単です。STRING などの BLOB フィールドを含むテーブルを SELECT * する場合は十分に注意してください。通常、BLOB の内容は別のページに保存されるため、DB のパフォーマンスが完全に低下する可能性があります。

小規模から中規模の結果セットには SELECT ... ENDSELECT を使用しないでください。代わりに SELECT ... INTO TABLE を使用してください。理由: SELECT ... INTO TABLE は単一のフェッチを実行し、カーソルを開いたままにしませんが、SELECT ... ENDSELECT は通常、ループの反復ごとに単一の行をフェッチします。

これは一種の都市伝説でしたSELECT。ループ ステートメントとして使用してもパフォーマンスが低下することはありません。ただし、これにより、ループ中にカーソルが開いたままになり、望ましくない (厳密にはパフォーマンス関連ではない) 影響が生じる可能性があります。

大きな結果セットの場合は、カーソルと内部テーブルを使用してください。 理由: 上記と同じで、ヒープ領域を使いすぎないようにします。

ORDER BY ではなく、代わりに SORT を使用してください。 理由: アプリケーション サーバーのスケーラビリティが向上します。

ネストされた SELECT ステートメントには注意してください。 小さな「内部結果セット」には非常に便利ですが、ネストされたクエリが大きな結果セットを返す場合、パフォーマンスが大幅に低下します。

測定、測定、測定 パフォーマンスが心配な場合は、何も想定しないでください。テスト データの代表的なセットを作成し、さまざまな実装のテストを実行します。ST05 と SAT の使用方法を学びます。

2 番目の質問を「一度だけ」閉じる方法はありません。まず、FOR ALL ENTRIES IN はデータベース テーブルと内部 (メモリ) テーブルを「結合」しますが、JOIN はデータベース テーブルに対してのみ動作します。データベースは内部 ABAP メモリについて何も知らないため、FOR ALL ENTRIES IN ステートメントは一連の WHERE ステートメントに変換されます。ST05 を使用してこれをトレースしてみてください。次に、FOR ALL ENTRIES IN を使用する場合、2 番目のテーブルから値を追加することはできません。第 3 に、FOR ALL ENTRIES IN は常に DISTINCT を意味することに注意してください。他にもいくつかの落とし穴があります。必ずオンラインの ABAP リファレンスを参照してください。それらはすべてそこにリストされています。

2 番目のテーブルのレコード数が少ない場合、両方のステートメントのパフォーマンスはほぼ同じである必要があります。データベース オプティマイザーは、2 番目のテーブルからすべての値を事前に選択し、スマート結合アルゴリズムを使用して最初のテーブルをフィルタリングする必要があります。私の推奨事項：コードを読みにくくするために微調整しようとしないでください。

2 番目のテーブルのレコード数が特定の値を超えると、FOR ALL ENTRIES IN で Bad Things [TM] が発生します。テーブルの内容が複数のセットに分割され、クエリが変換され (上記を参照)、再実行されます。セットごとに。

Answer 2

別の注意: 「Avoid SELECT *」ステートメントは一般的に正しいですが、どこが間違っているかはわかります。
とにかくほとんどのフィールドを取得する場合、およびフィールドのほとんどを取得するいくつかのクエリ (同じプログラム内、またはほぼ同時に実行される可能性が高い別のプログラム内) がある場合、特にフィールドが異なる場合欠落しているフィールド。

これは、App Server のデータ バッファーが select クエリの署名に基づいているためです。同じクエリを確実に使用する場合は、データベースに再度アクセスする代わりにバッファーを使用できることを確認できます。この場合、バッファが使用される可能性がはるかに高くなるため、SELECT * はフィールドの 90% を選択するよりも優れています。

また、私がテストした最後のバージョンの時点で、ABAP DB レイヤーは、SELECT A、B を SELECT B、A と同じものとして認識できるほどスマートではなかったことにも注意してください。つまり、取得するフィールドを常に同じ順序で配置する必要があります。アプリケーションのデータ バッファが適切に使用されていることを再度確認するためです。

Answer 3

私は通常、SAP の次の PDF に記載されている規則に従います。「ABAP を使用した効率的なデータベース プログラミング」では 、クエリを最適化するための多くのヒントが示されています。

Answer 4

この質問に完全に答えられることはありません。

データベースにアクセスするための ABAP ステートメントは、システム全体 (SAP および DB) のさまざまなコンポーネントによって何度も解釈されます。各コンポーネントの動作は、コンポーネント自体、そのバージョン、および設定によって異なります。解釈の主要部分は、SAP 側の DB アダプターで行われます。

最大のパフォーマンスを達成するための唯一の実行可能なアプローチは、特定のシステム (SAP バージョンと DB ベンダーとバージョン) で測定することです。

Answer 5

トランザクションSE30には、非常に広範なヒントもあります。それはあなたが（許可に応じて）あなた自身のコードスニペットを書いてそれを測定することさえ可能にします。

残念ながら、ランドスケープの設定方法、使用しているデータベースサーバー、テーブルインデックスの効率などに大きく依存するため、「すべてのエントリについて」と参加の議論を閉じることはできません。

単純な答えは、DBサーバーに可能な限り多くのことをさせることです。「すべてのエントリ」と参加の質問の場合、これは参加を意味します。経験豊富なすべてのABAPプログラマーを除いて、それがそれほど単純ではないことを知っています。vwegertが言ったように、さまざまなシナリオを試して測定する必要があります。また、ライブシステムでも測定することを忘れないでください。ハードウェア構成またはデータセットが大幅に異なり、ライブシステムでの結果がテストとはまったく異なる場合があります。