0

現在、ビジネス オブジェクトに対応する「フィルタ」オブジェクトがあります。このオブジェクトには、そのようなビジネス オブジェクトのリストをフィルタリング/検索できるようにするさまざまな方法に関連するプロパティがあります。現在、これらの Filter オブジェクトには、WHERE 句の内容を作成するメソッドがあり、SQL Server 2000 ストアド プロシージャに渡されて残りの選択クエリと連結されます。最後の文字列は、Execを使用して実行されます。

現在、これは問題なく動作しますが、実行計画のキャッシュがないことによるパフォーマンスの問題が心配です。いくつかの調査では、 sp_executesqlの呼び出しの使用を見てきました。これはより良い解決策ですか、それとも私がやっていることについてより良い慣習がありますか?

更新: sp_executesql の使用に関する問題の一部は、フィルターのコレクションに基づいて、OR ステートメントのリストを生成する必要があることだと思います。「パラメータ化された」クエリが私の解決策になるかどうかはわかりません。

例

    var whereClause = new StringBuilder();
    if (Status.Count > 0)
    {
       whereClause.Append("(");
       foreach (OrderStatus item in Status)
       {
          whereClause.AppendFormat("Orders.Status = {0} OR ", (int)item);
       }          

       whereClause.Remove(whereClause.Length - 4, 3);
       whereClause.Append(") AND ");
    }
4

5 に答える 5

3

sp_executesql は、プランの再利用のために exec よりも優れており、SQL インジェクションを防ぐのに役立つパラメーターを使用できます。sp_executesql を正しく使用すれば、プロシージャ キャッシュの膨張も発生しません。

この2つの記事を見てください

Exec の代わりに sp_executesql を使用して実行計画の変換を回避する

パラメータを正しく使用していない場合、exec を sp_executesql に変更してもメリットはありません。

于 2009-06-18T13:56:49.590 に答える
3

はい、sp_executesql は、実行するクエリの実行プランを "キャッシュ" します。

または、クエリの一部をストアド プロシージャに渡し、そこで完全なクエリを作成して動的 SQL を実行する代わりに、.NET 側でクエリ全体を作成し、ADO.NET コマンド オブジェクトを使用して実行することもできます。ADO.NET を介して実行されるすべてのクエリは、デフォルトで「キャッシュ」されます。

于 2009-06-18T14:00:24.357 に答える
1

あなたが言うように、クエリプランが保存され、将来の実行が最適化されるという理由だけで、sp_executesqlを使用する必要があります。また、一般的に実行よりも動的SQLを適切に処理するようです。

于 2009-06-18T13:56:26.690 に答える
0

最新の RDBMS (SQL Server 2000 を「最新の」RDBMS と見なすかどうかは実際にはわかりません) は、アドホッククエリ用に最適化されているため、パフォーマンスへの影響は (あったとしても) ごくわずかです。私を悩ませているのは、動的 SQL を構築するために sproc を使用していることです。これは、巨大なデバッグ/サポート PITA です。

于 2009-06-18T13:56:25.100 に答える