ストアドプロシージャと生のクエリの効率

私はこの議論の両側で多くを読みました：生のクエリではなくストアドプロシージャのみを使用することで得られるパフォーマンスの大幅な向上はありますか？私は特にSQL Serverに興味がありますが、ありとあらゆるデータベースに興味があります。

SQL Server 2008以降ではそれほどではありませんが、まだ存在しています。実行計画キャッシュとSQL Serverは、送信されるクエリを自動パラメーター化できます。ストアドプロシージャ（動的SQLが含まれていない）を使用する場合、クエリは既にパラメーター化されているため、SQL Serverはプランが既にプランキャッシュに格納されているため、実行時に各クエリのプランを生成する必要があります。

また、ストアドプロシージャを使用するとなくなるセキュリティの問題（動的SQL、最小権限など）を忘れないでください。

アプリがベーステーブルに対して動的SQLを使用してテーブル内のデータを選択、挿入、更新、および削除する場合、アプリケーションはこれらすべてのオブジェクトに対する権限を直接持っている必要があります。そのため、誰かがSQLインジェクションを使用してサーバーにアクセスした場合、それらのテーブルのすべてのデータを照会、変更、または削除する権限があります。

ストアドプロシージャを使用している場合、ストアドプロシージャを実行する権利のみがあり、ストアドプロシージャが返す情報のみを取得します。簡単な削除ステートメントを発行してすべてを吹き飛ばす代わりに、データを削除するために使用できる手順を把握し、その手順を使用する方法を把握する必要があります。

SQLインジェクションがデータベースに侵入する最も簡単な方法であることを考えると、これはちょっと重要です。

Dennyの回答の補遺として、procで使用されているクエリの結果として作成された、単一または低使用のアドホック実行プランでかなりのバッファプールメモリが浪費されるシステムを見つけることは珍しくありません。

最近の最悪のケースは、インスタンスに8GBが割り当てられ、3GBのプランキャッシュ、2.5GBのシングルユースプランです。これらの大部分はSQL2005であったため、アドホックワークロードの最適化設定を試すオプションではありませんでした。

生のクエリに対する手順の正当性にパフォーマンスを含めることは確かに難しくなっています。私にとっての最も強力な議論の1つは、「プロシージャを使用すると、パフォーマンスの問題が発生したときに支援するのがはるかに簡単になります」です。動的/ linq / ormインターフェースはチューニングを妨げませんが、オプションを大幅に制限する可能性があります。

SQL Serverは、同じ方法でストアドプロシージャとアドホックSQLをキャッシュして最適化します。たとえば、次の手順：

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

以下と同じように最適化およびキャッシュされます。

select * from Orders where id = @id

ただし、次のアドホックSQLは、値がハードコードされているため、効果的にキャッシュできません。

select * from Orders where id = 42

パフォーマンスは同じですが、ストアドプロシージャを使用する正当な理由があります。ストアドプロシージャは、DBAとアプリケーション開発者を明確に分離します。貴重なデータと絶えず変化するプログラムの間に追加の防御層を設けるのは良いことです:)