データベースで多くの読み取り/書き込みを行う .NET オブジェクトがあります。このオブジェクト (またはそれを使用する ASP ページ) のライフ サイクル全体で、1 ～ 10 回のクエリ/更新でデータベースにヒットする可能性があります。
オブジェクトがデータベースにヒットする必要があるたびにデータベース接続を開いたり閉じたりする代わりに、インスタンス化中にデータベースへの接続を開き、オブジェクトの終了イベント中に接続を閉じるだけです。それは悪い習慣ですか？
オブジェクトはインスタンス化されるたびに (通常は複数回) データベースにヒットするため、オブジェクトの寿命の最初に接続を開き、最後に閉じる方がよいと想定されていました。
もう 1 つの方法は、各クエリ/操作の前後にデータベース接続を開いたり閉じたりすることです。
パフォーマンスを最大化するためのベストプラクティスは何ですか?
****更新**** ヒントをありがとう。オブジェクトのインスタンス化/終了イベント内で接続を開始/終了する方法と、その影響について詳しく説明できる人はいますか?
必要に応じて、接続を開いたり閉じたりします。ADO.NET には、動作する接続プールが組み込まれています。数千回のオープン/クローズを伴うループでこれを実行しない限り、パフォーマンスの問題に気付くことはありません。
editデータ アクセス レイヤーで sqlconnection を永続化する必要がありますか? を 参照してください。接続の持続性の落とし穴に関する詳細については。
毎回開いて閉じる... 実際にデータベース操作を実行するコード行の直前に (できるだけ近くで) 開き、直後にできるだけ早く閉じます。この方法でこれを行うと、ADO.net は実際に接続を閉じるのではなく、接続を解放して ADO.net 接続プールに戻します。そこで、同じ接続文字列を持つ接続の次の要求を待ちます。毎回実際に接続を再作成するというオーバーヘッドが発生することはありません...
唯一の問題は、プール内の接続の最大数を超えるほど多くの接続試行を非同期で行っている場合です....そして、System.Threading.ThreadPool クラスを使用して、この問題に対する解決策もあります...
接続プールの信頼性を高めるために、接続を必要以上に長く開いたままにしておくと、実際には全体的なパフォーマンスが低下する可能性があります。これは、接続プールが DB 接続を必要とする他のコンポーネントとその接続を共有できないためです。
はい、必要に応じて接続を開いたり閉じたりしてください。ただし、クエリを単一の exec 呼び出しにバッチ処理できれば、さらに高速になります。
ado.net が実際に接続を閉じない場合でも、Conn.Close() を実行すると、サーバーで "sp_reset_connection" が実行されます。sp_reset_connection が軽量ストア プロシージャであっても、ネットワーク トラフィックが生成されます。たとえば、ループ内で接続を閉じたり開いたりすることはお勧めしません。