web-dev-qa-db-ja.com

ストアドプロシージャがクエリよりも高速な理由

データベースから1つの値のみを選択する単純な単一行クエリを作成します。

したがって、c＃コードで単純な選択クエリを記述するのではなく、このクエリのストアドプロシージャを記述すると、この単純な選択クエリのストアドプロシージャが高速になると確信していますが、なぜですか？

ストアドプロシージャとコード内の単純なクエリの記述と混同されていますか？なぜストアドプロシージャが、コードで直接記述された単純なクエリよりも高速であるのか混乱していますか？

c#sqlsql-serverstored-procedures
39
Ammar Raja

ストアドプロシージャはSQLコードよりも高速です

これはmythであり、パフォーマンスは本から常に同等です： ArchitectingMicrosoft®.NET Solutions for the Enterprise：

SQLは、データベースで実行する操作（クエリ、更新、または管理操作）に関する意思を宣言するための言語です。データベースエンジンが取得するのはテキストのみです。コンパイラによって処理されるC＃ソースファイルと同様に、SQLソースコードを何らかの方法でコンパイルして、一連の低レベルデータベース操作を生成する必要があります。この出力は、実行プランの名前の下になります。概念的には、実行計画の生成は、プログラムのコンパイルに対応するデータベースと見なすことができます。

ストアドプロシージャがプレーンなSQLコードに対して保証するパフォーマンスの向上は、実行計画の再利用にあります。つまり、SPを初めて実行するとき、DBMSは実行プランを生成してからコードを実行します。次回、以前に生成されたプランを再利用するだけなので、コマンドをより速く実行できます。すべてのSQLコマンドには実行計画が必要です。

（誤った）神話は、DBMSはストアドプロシージャに対してのみ実行計画を再利用するというものです。 SQL ServerとOracle DBMSに関する限り、実行計画を再利用する利点は、すべてのSQLステートメントに適用されます。 SQL Server 2005オンラインドキュメントから引用：

SQL Server 2005でSQLステートメントが実行されると、リレーショナルエンジンは最初にプロシージャキャッシュを調べて、同じSQLステートメントの既存の実行プランが存在することを確認します。 SQL Server 2005は、見つかった既存のプランを再利用し、SQLステートメントを再コンパイルするオーバーヘッドを節約します。既存の実行計画が存在しない場合、SQL Server 2005はクエリの新しい実行計画を生成します。

単純なSQLコードよりもパフォーマンスが良いSPに関する議論は無意味です。パフォーマンスに関しては、データベースにヒットするSQLコードはすべて同じように扱われます。コンパイルすると、パフォーマンスは同等になります。限目。

78
cuongle

これはクエリに依存します。単純なクエリの場合、クエリ自体として記述および実行するのが最適です。ただし、データベース側でより多くの処理を行う場合（カーソルでデータを取得して操作する場合など）、ストアドプロシージャはデータベースサーバーで実行するため、解析や余分な通信などの不要なオーバーヘッドを回避できます。 。

1
wizgot
"Stored procedures are precompiled and cached so the performance is much better."

これはSQL Server 2005まで真実であることがわかったとき、あなたにとっては心痛いことでした。この記事は神話を打ち砕きます ストアドプロシージャはパフォーマンスを向上させません

Microsoft Corp。のChrista Carpentiereが書いた 。NET開発者向けのストアドプロシージャの評価

0
Tahir77667