私はこの質問を「レポートタイプ」のクエリ（カウント、平均など、つまりドメインモデル自体を返さないもの）に集中させています.HQLを使用することで固有のパフォーマンス上の利点があるかどうか疑問に思っていました.二次キャッシュを活用できます。または、おそらくさらに良い - クエリ全体をキャッシュします。
明らかな暗黙の利点は、NHibernate がモデル マッピングについて既に知っているので、列名が何であるかを知っていることです。
他に知っておくべきメリットはありますか?
[私は NHibernate を使用していますが、この場合、Hibernate に適用されるものは NHibernate にも同様に適用されると思います]
メリットゼロです。HQL は、データの集計と計算を実行するための直接データベース クエリよりも優れたパフォーマンスを発揮しません。次のような結果：
Select count(*), dept from employees group by dept
HQL よりも DB の方が常に高速に実行されます。「あなたの状況に依存する」という考え方を取るのは不自由なので、私がいつも言っていることに注意してください。データとデータ集計に関係する場合。SQLで行います。
第 2 レベル キャッシュ内のオブジェクトは ID によってのみ取得されるため、Hibernate は常にクエリを実行して ID のリストを取得し、第 2 レベル キャッシュまたは別のクエリからそれらのオブジェクトを読み取ります。
一方、Hibernate はクエリをキャッシュして、場合によっては DB 呼び出しを完全に回避できます。ただし、クエリに含まれるテーブルを変更するとテーブルが無効になることを考慮する必要があるため、頻繁にキャッシュにヒットしない可能性があります。クエリキャッシュの仕組みについては、こちらを参照してください。
したがって、クエリがキャッシュされている場合、クエリのコストは 0 か、ストレート SQL でクエリを実行する場合とほぼ同じです。データが変更される頻度によっては、クエリ キャッシュを有効にすることで大幅に節約できる場合もあれば、何も保存しない場合もあります。
大量のクエリがあり、古い結果を許容できる場合は、x 分ごとに期限切れになる別のキャッシュをクエリ結果に使用する方がはるかに優れていると言えます。
私が考えることができる唯一の利点は、ORM クエリが通常 (準備された) ステートメント レベルでキャッシュされることです。そのため、同じクエリを何度も実行すると、準備されたステートメントを再利用している可能性があります。
しかし、クエリとパフォーマンスのレポートについて具体的に尋ねたので、実用的な利点は考えられません(データアクセスの一貫性、ORM クエリと SQL の比較などの他の利点があるという事実については、詳しく説明しています (ほとんどの場合、書く方が簡単です)。 HQL を使用したクエリ)、データ型変換など)
HQL はオブジェクト クエリ言語です。SQL はリレーショナル クエリ言語です。