データベースから値を 1 つだけ選択する単純な 1 行のクエリを作成したいと考えています。
したがって、C# コードで単純な選択クエリを記述するのではなく、このクエリのストアド プロシージャを記述した場合、この単純な選択クエリのストアド プロシージャの方が高速になると確信していますが、なぜでしょうか?
ストアド プロシージャとコードでの単純なクエリの記述とで混乱していますか? コードで直接記述された単純なクエリよりもストアド プロシージャの方が高速なのはなぜでしょうか。
35314 次
5 に答える
93
ストアド プロシージャは SQL コードよりも高速です
これは神話であり、パフォーマンスは常に同等であるという本から: Architecting Microsoft® .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 コードはすべて同じように扱われます。コンパイル後のパフォーマンスは同等です。限目。
于 2012-10-18T06:34:40.507 に答える
1
これはクエリによって異なります。単純なクエリの場合は、クエリ自体として記述および実行するのが最適です。ただし、データベース側でより多くの処理を行う必要がある場合 (カーソル内のデータを取得して操作する場合など)、データベース サーバー上で実行し、解析や余分な通信などの不要なオーバーヘッドを回避するため、ストアド プロシージャの方が優れています。 .
于 2012-10-18T06:27:54.390 に答える
-2
ストアド プロシージャは、データベースに格納されたクエリです。それらはプリコンパイルされています。データベースにストアド プロシージャ (SQL Server) の実行を要求すると、SQL Server には既にストアド プロシージャの実行計画があります。単純なクエリでは、実行時に実行計画を作成する必要があります。ここでもっと勉強する必要があります
于 2012-10-18T06:29:40.887 に答える
-3
ストアドプロシージャはプリコンパイルおよび最適化されているため、クエリエンジンでより迅速に実行できます。対照的に、コード内のクエリは、実行時に解析、コンパイル、および最適化する必要があります。これにはすべて時間がかかります。
于 2012-10-18T06:25:04.353 に答える