Hibernate——条件与命名查询答案

【问题标题】：Hibernate -- Criteria vs named queryHibernate——条件与命名查询
【发布时间】：2014-05-26 08:14:21
【问题描述】：

我正在尝试将 Hibernate Criteria 与命名查询的性能进行比较。我知道这一切都取决于实际查询本身，最后一句话是关于它们在运行时的配置方式。仍然，试图理清每个内容。

我尝试将 Q 分为两部分并在两者上寻找验证/更正：

PART-1 -- Hibernate Criteria 和命名查询的基本工作原理：

标准适用于参数。在运行时，查询不需要解析——有几个搜索和“呈现形式”参数，如排序结果，将它们作为可滚动返回等。尚未阅读/验证此内容，但标准适用于字段索引（基于字段上设置的参数）让这一切更快。

因此，与普通 HQL 相比，Criteria 的优势是它在执行过程中的速度。

命名查询与 HQL 相比具有相同的优势—— 查询在启动时解析一次。然后执行从应用程序中的任何必要位置。

PART-2——比较两者：

所以在这张照片中，

条件和命名查询如何相互比较？

条件适用于跨多个表的复杂查询和多个参数——有优化的方法，从而使查询快速（？）

命名查询具有“define-once-use-everywhere”的优点，并且对于“轻量级”查询来说还不错—— 通常在单个表上使用少量参数进行不太复杂的搜索。在频繁查询时甚至更好。

注意：在其他一些讨论中看到了非常有用的Hibernate Criteria vs HQL: which is faster?。

TIA。

【问题讨论】：

标签： hibernate orm criteria named-query

【解决方案1】：

您不会根据性能选择其中之一。最终还是变成了 SQL 查询，重要的是 SQL 查询的性能。

执行 SQL 查询比解析 HQL 查询并将其转换为 SQL 慢几个数量级。所以即使不使用命名查询，性能也不会明显变差。

您根据功能和可读性选择标准而不是 HQL。

如果您想要一些可读的内容，请使用 HQL 查询。

如果您想根据各种可选的搜索条件动态组合查询，则 Criteria API 允许这样做，并且比动态组合 HQL 查询更方便。

【讨论】：

【解决方案2】：

Criteria 理论上应该比 HQL 查询具有更少的开销（命名查询除外，我将介绍它）。这是因为 Criteria 不需要解析任何内容。 HQL 查询使用基于 ANTLR 的解析器进行解析，然后将生成的 AST 转换为 SQL。但是，使用 HQL/JPAQL，您可以定义命名查询，其中 SQL 在 SessionFactory 启动时生成。理论上，命名查询的开销比 Criteria 少。因此，就 SQL 生成开销而言，我们有：

命名的 HQL/JPAQL 查询 - SQL 生成只发生一次。
标准 - 生成前无需解析。
（未命名）HQL/JPAQL 查询 - 解析，然后生成。也就是说，在我看来，根据解析和 SQL 生成的开销来选择查询技术可能是一个错误。与在具有真实数据的真实数据库服务器上执行真实查询相比，这种开销通常非常小。如果在分析应用程序时确实出现了这种开销，那么也许您应该切换到命名查询。

在选择 Criteria 和 HQL/JPAQL 时，我会考虑以下几点：

首先，您必须确定是否可以依赖代码中的 Hibernate 专有 API。 JPA 没有标准。
Criteria 非常擅长处理许多可选的搜索参数例如您可能会在具有多参数的典型网页上找到 '搜索表格'。使用 HQL，开发人员倾向于使用 where 子句使用 StringBuilder 的表达式（避免这种情况！）。使用标准，您不需要这样做。
HQL/JPAQL 可用于大多数其他事情，因为代码倾向于更小更易于开发人员理解。
如果你使用真正频繁的查询可以变成命名查询高质量的。在进行一些分析之后，我更愿意稍后再执行此操作。

【讨论】：