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 回答