私たちの DBA は、SQL サーバー データベースに対して実行時間の長いクエリを持って戻ってきました。彼は、そのクエリを見直して、最適化できるかどうかを確認する必要があると考えました。
問題は、クエリがアプリケーション コードから来ていないことです。主キーによって単一のテーブルから多数のレコード (正確には 9 つ) をロードしています。アプリケーションから主キーによってそのテーブルにクエリを実行することはありません。また、休止状態が行う名前マングリングとすべてのプロパティのロードによる休止状態クエリでもあります。
したがって、後で必要になると思われるレコードをプルするなど、休止状態が予測キャッシュを行うかどうか疑問に思っています。これについて何か意見はありますか？
ありがとう。
これはおそらく、バッチ フェッチによって実行されるクエリです。
バッチ フェッチを使用すると、Hibernate は、1 つのプロキシがアクセスされた場合に、初期化されていない複数のプロキシをロードできます。バッチ フェッチは、レイジー セレクト フェッチ戦略を最適化したものです。
クラス/エンティティのバッチ フェッチは理解しやすいです。次の例を考えてみましょう。実行時に 25 個の Cat インスタンスが Session にロードされ、各 Cat はその所有者である Person への参照を持っています。Person クラスはプロキシ lazy="true" でマップされます。すべての cat を反復処理し、それぞれに対して getOwner() を呼び出すと、Hibernate はデフォルトで 25 の SELECT ステートメントを実行して、プロキシされた所有者を取得します。Person のマッピングでバッチサイズを指定することで、この動作を調整できます。
<class name="Person" batch-size="10">...</class>Hibernate は 3 つのクエリのみを実行するようになりました: パターンは 10、10、5 です。
Hibernate は、バッチ fetching/subselect fetching を除いて、独自に予測キャッシュを実行しません。
ただし、Hibernate はユーザーが要求したエンティティを暗黙的にフェッチできます。たとえば、熱心な関係のターゲットをフェッチし、怠惰な関係の場合はアクセスされた怠惰なプロキシを初期化します。
そのため、問題のテーブルがいくつかのリレーションシップのターゲットとして機能する場合、これらのリレーションシップが熱心であるかどうか、およびそれらが遅延している場合はどのようにアクセスするかを確認する必要があります。