Hibernate Criteria vs HQL：哪个更快？

Question

我一直在读一些回答，但我仍然感到困惑。为什么？因为你提到的差异与绩效无关。它们与易用性有关。（Objetc（标准）和SQL（hql））。但我想知道“条件”是否因某种原因比hql慢。

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

“HQL和criteriaQuery之间的性能存在差异，每次使用criteriaQuery触发查询时，它都会为表名创建一个新别名，该别名不会反映在任何数据库的最后一个查询缓存中。这会导致编译生成的SQL的开销，花费更多的时间来执行。“作者：Varun Mehta。

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

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

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

Answer 1

我是2004年编写Hibernate 3查询翻译器的人，因此我知道它是如何工作的。

标准，理论上应该比HQL查询具有更少的开销（命名查询除外，我将会得到）。这是因为Criteria不需要解析任何东西。使用基于ANTLR的解析器解析HQL查询，然后将生成的AST转换为SQL。但是，使用HQL / JPAQL，您可以定义命名查询，其中SQL生成时 SessionFactory启动。理论上，命名查询的开销小于Criteria。

因此，就SQL生成开销而言，我们有：

1. 命名为HQL / JPAQL查询 - SQL生成只发生一次。
2. 标准 - 生成前无需解析。
3. （非命名）HQL / JPAQL查询 - 解析，然后生成。

那就是说， 在我看来，选择基于解析和SQL生成开销的查询技术可能是一个错误 。与使用真实数据在真实数据库服务器上执行实际查询相比，此开销通常非常小。如果在分析应用程序时实际显示此开销，那么可能您应该切换到命名查询。

在Criteria和HQL / JPAQL之间做出决定时，我会考虑以下事项：

• 首先，您必须在代码中确定确定是否依赖于Hibernate专有API 。 JPA没有标准。
• 标准非常擅长处理许多可选搜索参数，例如您可能会在具有多参数“搜索表单”的典型网页上找到这些参数。使用HQL，开发人员倾向于使用StringBuilder来处理where子句表达式（避免这种情况！）。使用Criteria，您不需要这样做。哈迪克发表了类似的意见。
• HQL / JPAQL可以用于大多数其他事情，因为代码往往更小，更容易让开发人员理解。
• 如果使用HQL，可以将频繁查询转换为命名查询。经过一些分析后，我宁愿稍后这样做。

Answer 2

我正在研究数百万的记录。我发现HQL比Criteria快得多。标准在绩效方面落后很多。

如果您要处理大量数据，请转到HQL。

Answer 3

我更喜欢Criteria Queries进行动态查询。例如，根据某些参数，动态添加一些排序或保留一些部分（例如限制）要容易得多。

另一方面，我正在使用HQL进行静态和复杂查询，因为它更容易理解/读取HQL。另外，我认为HQL更强大，例如对于不同的连接类型。

JPA and Hibernate - Criteria vs. JPQL or HQL

Answer 4

我认为针对HQL的标准的其他优势：

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

在编写Criteria Queries时，IDE建议我们使用Intellisense，因此除非我们在双引号中写出变量名这样的内容，否则提交错误的可能性会更小。

Answer 5

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