Hibernate -标准与命名查询

Question

我正在尝试将Hibernate Criteria与命名查询进行性能比较。我知道这一切都取决于实际查询本身，最后一个词是它们在运行时的配置文件。尽管如此，仍在尝试整理每个查询的内容。

我试图将Q分为两部分

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

Criteria适用于参数。在运行时，查询不需要解析——有几个搜索和“表单存在”参数，例如对结果进行排序，将它们返回为可滚动的等。还没有阅读/验证过这一点，但Criteria通过字段的索引（基于在字段上设置的参数）来工作，以使其更快。

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

命名查询与HQL相比也有同样的优势——查询在启动时被解析一次。然后从应用程序中任何需要的地方执行。

PART-2--比较两者：

所以在这张图片中，

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

Criteria适用于跨多个表和多个参数的复杂查询——能够优化查询，从而使查询更快(？)

命名查询具有“随处定义一次”的优势，非常适合“轻量级”查询——通常在单个表上使用少量参数的不太复杂的搜索。在频繁查询上甚至更好。

注意:看过非常有用的Hibernate标准和HQL:哪个更快？在其他一些讨论中。

蒂亚。

Answer 1

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

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

以下是我在决定标准和HQL/JPAQL时考虑的事项：

• 首先，您必须确定是否可以在代码中依赖Hibernate专有API。JPA没有标准。
• 条件非常擅长处理许多可选的搜索参数，例如您可能在具有多参数“搜索表单”的典型网页上找到的参数。使用HQL，开发人员倾向于使用StringBuilder附加子句表达式的位置（避免这种情况！使用条件，您无需执行此操作。
• HQL/JPAQL 可以用于大多数其他事情，因为代码往往更小，更容易被开发人员理解。
• 如果使用 HQL，则可以将真正频繁的查询转换为命名查询。我更喜欢在经过一些分析之后再这样做。

Answer 2

您不会基于性能来选择其中一个。最终，它将成为一个SQL查询，重要的是SQL查询的性能。

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

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

如果需要可读的内容，请使用 HQL 查询。

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