73

我一直在阅读一些答案,但我仍然感到困惑。为什么?因为您提到的差异与性能无关。它们与易于使用有关。(Objetc(标准)和 SQL(hql))。但我想知道“标准”是否由于某种原因比 hql 慢。

我在另一个答案中读到了这个

“HQL 和条件查询之间的性能存在差异,每次使用条件查询触发查询时,它都会为表名创建一个新别名,该别名不会反映在任何数据库的最后查询缓存中。这会导致开销编译生成的 SQL,需要更多时间来执行。” 通过瓦伦梅塔。

这是非常接近的但是!我在另一个网站上阅读(http://gary-rowe.com/agilestack/tag/hibernate/)Hibernate 3.3 及更高版本不再是这种情况(请阅读:9)Hibernate 很慢,因为生成的 SQL Criteria接口不一致)

我做了一些测试,试图找出差异,但两者都生成 qry,并且不会更改表的别名。

我很困惑。如果有人知道主要原因,请帮助我们。谢谢

4

5 回答 5

154

我是 2004 年编写 Hibernate 3 查询翻译器的人,所以我知道它是如何工作的。

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

因此,就 SQL 生成开销而言,我们有:

  1. 命名 HQL/JPAQL 查询 - SQL 生成只发生一次。
  2. 标准 - 生成前无需解析。
  3. (未命名)HQL/JPAQL 查询 - 解析,然后生成。

也就是说,在我看来,根据解析和 SQL 生成的开销来选择查询技术可能是一个错误。与在具有真实数据的真实数据库服务器上执行真实查询相比,这种开销通常非常小。如果在分析应用程序时确实出现了这种开销,那么也许您应该切换到命名查询。

以下是我在 Criteria 和 HQL/JPAQL 之间做出决定时考虑的事项:

  • 首先,您必须确定是否可以代码中依赖 Hibernate 专有 API。JPA 没有标准。
  • Criteria 非常擅长处理许多可选的搜索参数,例如您可能会在具有多参数“搜索表单”的典型网页上找到。使用 HQL,开发人员倾向于使用 StringBuilder 来处理 where 子句表达式(避免这种情况!)。使用 Criteria,您无需这样做。哈迪克发表了类似的观点。
  • HQL/JPAQL 可用于大多数其他事情,因为代码往往更小,更易于开发人员理解。
  • 如果您使用 HQL,则可以将真正频繁的查询转换为命名查询。在进行一些分析之后,我更愿意稍后再做这件事。
于 2011-01-22T20:59:36.877 回答
9

我正在处理数百万条记录。我发现 HQL 比 Criteria 快得多。标准在性能上滞后很多。

如果您要处理大量数据,请选择 HQL。

于 2012-11-14T01:19:13.780 回答
7

我最喜欢动态查询的条件查询。例如,根据某些参数动态添加一些排序或保留一些部分(例如限制)要容易得多。

另一方面,我将 HQL 用于静态和复杂查询,因为它更容易理解/阅读 HQL。此外,我认为 HQL 更强大一些,例如对于不同的连接类型。

JPA 和 Hibernate - 标准与 JPQL 或 HQL

于 2011-01-13T10:23:55.717 回答
7

我认为 Criteria over HQL 的其他优势

编写 HQL 会使代码变得混乱。它看起来不再像编写干净的面向对象代码了。

在编写 Criteria Queries 时,IDE 建议我们使用 Intellisense,因此除非我们在双引号中编写变量名之类的东西,否则犯错的可能性会更小。

于 2016-07-11T07:35:35.647 回答
4

你是对的,不是的。结果列表是从数据库或缓存中检索到的org.hibernate.loader.Loader类。未启用缓存时,使用在 SessionFactoryImp 中创建的 Dialect 对象构建准备好的语句。因此,每个列表调用都会初始化语句。此外,低级查询是自动生成的。基本上,它是一种帮助,但在某些情况下,手动编写特定查询会更有效。

于 2016-11-05T08:34:06.800 回答