次の質問がありましたが、ストアドプロシージャのパフォーマンスを向上させたい場合、どのように調べますか?ストアドプロシージャは何らかの値を返し、3つの結合が含まれています。結合が適切に記述されていることを確認する以外に、パフォーマンスを向上させるために何ができるでしょうか。これは一般的な質問であり、コードは提供されませんでした。何か案は?
5 に答える
結合で使用されるテーブルのインデックスを確認します。特に、結合で使用される列は索引付けされていますか?
例 -
SELECT *
FROM SomeTable a
JOIN SomeOtherTable b on a.ItemId = b.ItemId
ItemId
これらのテーブルが大きい場合、通常、両方のテーブルでインデックスを作成すると、パフォーマンスが大幅に向上します。
WHERE
クエリに列がある場合は、句で使用される列に対して同じことを行う必要があります。
WHERE a.ProductId = @SomeVariableYouPassedToTheStoredProc
ProductId
この場合、インデックス作成が役立ちます。
クエリのパフォーマンスはうさぎの穴に入る可能性がありますが、これは論理的な (そして迅速な) 出発点です。
SQL ステートメントでクエリ アナライザを実行する
他にも選択肢があると思います。例: 1. これらの各結合では、「and permited_used_name = (select user_name from user_list where )」のような制限条件を使用できます。多くの同様のクエリによってDBが過負荷にならないように、プロシージャの開始時(つまり、プロシージャの最初の文字列)に値を1回導出できます。2. Oracle11 からは、キャッシュされた結果を持つ関数として関数を宣言できます (つまり、関数は一度計算され、呼び出されるたびに再計算されません) 無効化キャッシュを変更する一連のテーブルを定義します。
いずれにせよ、問題はほとんど DB 固有のものです。
手順を最適化するためにできることはたくさんありますが、SQL ステートメントは非常に単純に思えます。注意すべき点:
- インライン関数。これらにより、SQL が行ごとに評価を行い、速度が低下する可能性があります。
- 結合ステートメントでのデータ変換。これらは、インデックスの使用を妨げる可能性があります。
- where句で結合されている列がインデックス付けされていることを確認してください(大規模なデータセットの場合)
パフォーマンスのヒントについては、この Web サイトを参照してください。簡単なステートメントに必要なもののほとんどを説明したと思います。
それがストアド プロシージャであるという事実は、それとはほとんど関係がありません。内部のSQLを最適化します。
どのように、あなたが何が悪いのか推測できると考えている種類の eejit によって書かれたものを含め、すべての通常の容疑者。
proc から適切なツールに sql をコピーし、Explain を前に付けて、何が起こっているかを確認します。