Hibernate Criteria vs HQL:哪个更快？

Question

我一直在读一些回忆录，但我还是很困惑。为什么？因为您提到的差异与性能无关。它们与易用性有关(Objetc(标准)和SQL(hql))。但我想知道"criteria“是不是因为某种原因比hql慢。

我在另一本书里读到了这篇文章

HQL和criteriaQuery在性能方面存在差异，每次您使用criteriaQuery触发查询时，它都会为表名创建新的别名，该别名不会反映在任何数据库的上次查询缓存中。这会导致编译生成的SQL的开销，从而花费更多时间执行。瓦伦·梅塔写的。

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

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

我很困惑。如果有人知道主要原因，你能帮助我们吗？谢谢

Answer 1

我是在2004年编写Hibernate 3查询翻译器的人，所以我对它的工作原理有所了解。

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

因此，在SQL生成开销方面，我们有：

1. 命名HQL/JPAQL查询- SQL生成只发生一次。
2. 条件-在SQL HQL/JPAQL查询之前不需要解析-解析，然后生成。

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

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

• 首先，你必须决定在你的代码中对Hibernate专有的依赖是否合适。JPA没有Criteria.
• Criteria，它非常擅长处理许多可选的搜索参数，就像你在一个典型的带有多参数“搜索表单”的网页上看到的那样。有了HQL，开发人员倾向于用StringBuilder来添加where子句表达式(避免使用！)。有了标准，你就不需要这么做了。Hardik发布的类似opinions.
• HQL/JPAQL可以用于大多数其他事情，因为如果使用understand.
• Really，代码往往更小，开发人员更容易将频繁查询转换为命名查询。我更喜欢在分析之后再做这件事。

Answer 2

我正在制作数百万张唱片。我发现HQL比Criteria快得多。Criteria在性能上有很大的滞后。

如果您正在处理大量数据，则使用HQL。

Answer 3

对于动态查询，我更喜欢使用条件查询。例如，根据某些参数动态添加一些排序或省略某些部分(例如限制)要容易得多。

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

JPA and Hibernate - Criteria vs. JPQL or HQL