4

I have a simple SELECT statement with a couple columns referenced in the WHERE clause. Normally I do these simple ones in the VB code (setup a Command object, set Command Type to text, set Command Text to the Select statement). However I'm seeing timeout problems. We've optimized just about everything we can with our tables, etc.

I'm wondering if there'd be a big performance hit just because I'm doing the query this way, versus creating a simple stored procedure with a couple params. I'm thinking maybe the inline code forces SQL to do extra work compiling, creating query plan, etc. which wouldn't occur if I used a stored procedure.

An example of the actual SQL being run:

SELECT TOP 1 * FROM MyTable WHERE Field1 = @Field1 ORDER BY ID DESC
4

4 に答える 4

5

整形式の「インライン」または「アドホック」SQL クエリは、パラメータを適切に使用すれば、ストアド プロシージャと同じくらい優れています。

しかし、これは非常に重要です: 適切にパラメータ化されたクエリを使用する必要があります! そうでない場合 (リクエストごとに SQL を連結する場合) 、これらの点から恩恵を受けることはありません...

ストアド プロシージャと同様に、最初の実行時にクエリ実行プランを見つける必要があります。その後、ストアド プロシージャと同様に、その実行プランがプラン キャッシュにキャッシュされます。

インラインのパラメーター化された SQL ステートメントを複数回呼び出すと、そのクエリ プランは何度も再利用されます。また、「インライン」SQL クエリ プランは、ストアド プロシージャの実行プランと同じキャッシュ エビクション ポリシーの対象となります。

その観点からすると、適切にパラメータ化されたクエリを実際に使用している場合、ストアド プロシージャのパフォーマンス上の利点はありません。

ストアド プロシージャには他にも利点がありますが (「セキュリティ境界」など)、生のパフォーマンスだけが主要な利点の 1 つではありません。

于 2012-08-22T15:14:57.947 に答える
0

データベースがあなたが言及した余分な作業をしなければならないことは事実ですが、それはパフォーマンスに大きな影響を与えるべきではありません（クエリを非常に頻繁に実行していない限り..）

SQL プロファイラーを使用して、実際にサーバーに送信されているものを確認します。アクティビティ モニターを使用して、自分のクエリをブロックしている他のクエリがあるかどうかを確認します。

于 2012-08-22T15:13:15.817 に答える