sql - 長時間実行されるトランザクションのストアド プロシージャでのパフォーマンスの向上

Question

5 ～ 10 分かかる長時間実行レポート タイプのトランザクションがいくつかあります。ストアド プロシージャを使用するとパフォーマンスが向上しますか? それは重要でしょうか？

各クエリは 1 晩に 1 回実行されます。

Answer 1

おそらくそうではありません。ストアド プロシージャは、プリコンパイル済み SQL の利点を提供します。SQL が頻繁に呼び出されない場合、この利点はほとんど価値がありません。そのため、クエリ自体が高価であるために高価な SQL を使用している場合、ストアド プロシージャを使用しても意味のあるパフォーマンス上の利点は得られません。非常に頻繁に呼び出され、それ自体がすばやく実行されるクエリがある場合は、proc を使用する価値があります。

Answer 2

ほとんどの場合、そうではありません。ストアド プロシージャからのパフォーマンスの向上 (ユース ケースによって異なります) は、マイクロでは目立たない種類のものであり、マクロでのみです。

レポート型のクエリは大量のデータを集計するクエリであり、その場合、実行方法に関係なく遅くなります。インデックス作成および/またはその他の物理データの変更のみが高速化できます。

見る：

一般に、ストアド プロシージャは最新の RDBMS のインライン ステートメントよりも効率的ですか?

Answer 3

簡単に言えば、いいえ、ストアド プロシージャによってパフォーマンスが向上することはありません。まず、パラメーター化されたクエリを使用している場合、ストアド プロシージャとインライン SQL のパフォーマンスに違いはありません。その理由は、ストアド プロシージャだけでなく、すべてのクエリに実行プランがキャッシュされているためです。http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspxをご覧ください。

インライン クエリをパラメータ化せず、クエリを構築して「パラメータ」をリテラルとして挿入するだけの場合、各クエリはデータベースに対して異なって見えるため、それぞれを事前にコンパイルする必要があります。したがって、この場合、インライン SQL でパラメーターを使用することで、自分自身に有利に働くことになります。とにかく、セキュリティの観点からこれを行う必要があります。そうしないと、SQL インジェクション攻撃にさらされることになります。

しかし、とにかく、コンパイル前の問題はここでは厄介です。あなたは長時間実行されるクエリについて話している-事前コンパイルが重要でなくなるほど長い。残念ながら、ここで簡単に降りることはできません。あなたの解決策は、クエリの実際の設計を最適化すること、またはタスクにアプローチする方法全体を再考することです。

Answer 4

はい、ストアド プロシージャのクエリ プランは最適化できます。最適化できない場合でも、組み込み SQL よりもプロシージャが優先されます。

「パフォーマンスの改善が見られますか」 - 確実に知る唯一の方法は、試してみることです

理論的には、ストアド プロシージャは毎回計算するのではなく、SQL を事前に解析し、クエリ プランを保存するため、それだけで速度が向上するはずですが、5 ～ 10 分のプロセスで重要になるとは思えません。

速度が重要な場合は、クエリ プランを調べて、さまざまなクエリ構造やインデックスなどを追加することで改善できるかどうかを確認することをお勧めします。

速度が重要でない場合、ストアド プロシージャはインライン SQL よりも優れたカプセル化を提供します。

Answer 5

他の人が言ったように、プリコンパイルされたストアド プロシージャからパフォーマンスが大幅に向上することはありません。ただし、現在のトランザクションに複数のステートメントがあり、データがサーバー間を行き来している場合、ストアド プロシージャでそれをラップすると、実際のパフォーマンス キラーになる可能性があるそのやり取りの一部を排除できます。

適切なインデックス作成を調べますが、クエリ自体 (または複数の手順で構成される場合はプロセス全体) が非効率である可能性があるという事実も考慮してください。実際のコードを見ないと、なんとも言えません。