1

これは、SQL コマンドの最適化に関する問題ではありません。SQL 接続を開いたままにして、コマンドをできるだけ効率的に処理できるようにする方法を考えています。

私が今見ているのは、SQL コマンドを実行でき、そのコマンドには約 1 秒かかり、追加の実行には約 300 ミリ秒かかるということです。これは、(別のアプリケーション インスタンスから) SQL サーバーに対してコマンドが以前に実行された後であるため、このアプリケーションの最初の実行の前に、実行されたクエリに対して SQL キャッシュを完全に設定する必要があります。クエリを継続的に再実行している限り、約 300 ミリ秒の時間が表示されますが、アプリケーションを 5 ～ 10 分間アイドル状態のままにしておくと、次の要求は ~1 秒 (最初の要求と同じ) に戻ります。

接続文字列または SqlConnection のいくつかのプロパティを介してフレームワークに指示し、接続を水和させ、クエリを効率的に処理する準備を整える方法はありますか?

4

5 に答える 5

2

.NET接続プールで開いている接続のデフォルト値はゼロです。

接続文字列のこの値を1以上に調整できます。

"data source=dbserver;...Asynchronous Processing=true;Min Pool Size=1"

これらのオプションの詳細については、MSDNを参照してください。

于 2009-07-06T04:31:46.073 に答える
2

手順の実行計画を確認しましたか。私が信じている実行計画は、サーバー上のメモリにロードされ、一定の時間が経過した後、または手順でアクセスされるテーブルなどに応じてクリアされます。ストアド プロシージャを単純化する (おそらくそれらを分割する) ことで、データベース サーバーが計画を計算する際に実行する必要のある作業量が削減され、最終的にプロシージャが最初に呼び出される時間が削減されるケースがありました...次のコマンドを発行できます。最初の呼び出し時間を短縮しているかどうかをテストするために、毎回ストアド プロシージャを強制的に再コンパイルします... ストアド プロシージャの複雑さが原因で、データベース サーバーがさまざまなパラメータに基づいて継続的に再コンパイルしなければならず、大幅に速度が低下する場合がありました。

他のアイデアは、おそらく断続的に単純な getDate() などを頻繁に呼び出すことで、SQL サーバーが起動していることを願っています (それが理にかなっていることを願っています)... IIS のメモリに asp.net アプリを保持するのとほぼ同じです。

于 2009-07-03T09:45:53.430 に答える
0

閉じずに開いたままにします。:)しかし、接続プールが接続管理を処理するため、これはお勧めできません。有効にしていますか？

于 2009-07-03T09:40:29.823 に答える
0

デフォルトでは、ADO .NET で接続プールが有効になっています。これは、アプリケーションが使用する接続文字列を介して行われます。SQL Server での接続プールの使用に関する詳細情報

于 2009-07-03T09:47:17.187 に答える
0

複数のデータベース接続を使用する場合は、より効率的です。データベース接続が 1 つあるということは、可能な限り最高のアクセス速度が常に順次制限されることを意味します。一方、1 つ以上の接続があるということは、コンパイラが同時アクセスをもう少し最適化する機会があることを意味します。.NET を使用していると思いますか?

また、同じ SQL ステートメントを繰り返し発行する場合、データベース サーバーが結果を短時間キャッシュしている可能性があるため、結果セットの戻りが速くなります。

于 2009-07-03T09:49:24.077 に答える