一度に1 つしか使用Statement
しない場合は、Connection
. 私はすでに接続をキャッシュしているので、ほとんどコストをかけずにステートメントをキャッシュできました。
基本的に、ステートメントを作成するためのコスト/オーバーヘッドがあるかどうかを尋ねていると思います。準備済みステートメントを作成する利点を十分に理解しています。私はConnection.createStatement()
ここについて具体的に話しています。
ステートメントのコストは、他の要因から独立して定量化することはできません。たとえば、データベース、JDBC ドライバー、ステートメント内の SQL などです。
Statement (または PreparedStatement) を作成し、それを初めて実行する際にオーバーヘッドが発生することは確実です。ただし、アプリケーション全体のパフォーマンスにとって重要ではない可能性は十分にあります。そうでない場合は、キャッシュ コードを実装するだけで無駄な作業になります。
これが価値のある最適化になるかどうか (またはそうでないかどうか) を推測するべきではありません。あなたがしなければならないことは、プログラムを動作させ、プロファイリングし、プロファイリング データを使用して最適化が必要なものを判断することです。同じクエリの実行にかなりの時間が費やされている場合、キャッシュが役立つ場合とそうでない場合があります。試してみて、パフォーマンスに測定可能な違いがあるかどうかを確認してください。
オープンソースの jdbc ドライバー ( jtds )に関するいくつかの調査では、作成されたステートメントごとに次のオブジェクト オーバーヘッドが生じることが示唆されています。Statement
データベースにクエリを実行するたびに、キャッシュされたデータベースを 1 つ保持して再利用するのではなく、新しいデータベースを作成するコストを数えようとしています。
Connection
- おそらくキャッシュされているため、重要ではありません。TdsCore
- プロトコルの実装のように見えますが、キャッシュされているため重要ではありません。ResultSet
_ArrayList
バッチ処理されたアイテムの。ArrayList
オープンResultSet
s の。Statement
したがって、 s のコストの最も高い割合は、実行されたクエリによって残されたものに関係しているように見えます。