Criteria v/s HQL .who更快？

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

总体而言，如果您使用HQL或Criteria来创建最终的SQL，那么在Hibernate的后续版本( 3.3版及更高版本)中，您将不会看到性能上的太大差异。

要测试这一点，您需要在HQL和使用Criteria界面中创建一个代表性查询。然后记录来自Hibernate逐渐老版本的结果SQL (可能使用Maven以允许快速版本更改)。您将注意到，随着Hibernate版本的减少，您将在最终的SQL中看到更改。

尝试在HQL和代码中的条件之间进行优化几乎没有什么意义，因为损失的绝大多数时间将是在应用程序和数据库之间的网络流量中。当然，这假设您有一个格式良好的查询，该查询不需要超过1亿行的多次全表扫描。

quoted blog is attempting to debunk myths所以要小心，不要断章取义(强调我的)：

9) "Hibernate很慢，因为Criteria接口生成的SQL不一致“

有人说，如果所有的查询都是通过Criteria接口而不是直接在HQL中构造的，那么Hibernate也会导致性能损失。争论认为这是因为每次执行查询构建器代码时，Hibernate都会为查询中的表生成新的别名。在Oracle中，这意味着每次运行新的基于标准的查询时，数据库都必须创建一个QEP查询执行计划-因为它无法匹配缓存中提供给任何查询的SQL。创建QEP的时间可能是Oracle响应SQL语句所用时间的30%，因此对于第二次和后续执行相同的SQL语句(别名除外)，Criteria具有内置的开销，这使其比直接HQL慢50%。

这不再是Hibernate 3.3和更高版本的情况。因为Hibernate团队肯定会尽可能地创建最优的，，如果它是真的，那也是值得怀疑的。独立测试表明，在跨事务的重复调用之后，Criteria接口会生成相同的查询，这等同于在负载下运行应用程序。在每种情况下，查询都保持不变，因此Oracle可以对其进行缓存。

但有一点是有道理的，那就是每次都需要使用Criteria接口创建查询，而使用HQL中定义的命名查询允许在应用程序启动期间进行预编译。然而，这需要一些观点。在一台普通的PC上，使用Criteria界面创建一个简单的“介于”查询所需的时间大约是3ms。在应用程序中嵌入HQL不是一个好的选择，因为它不会产生一种直观的机制来维护具有不同获取策略的查询，因此基于标准的方法被认为是两种方法中较好的一种。

因此，博客基本上指出，主要区别在于Criteria接口可能会引入几毫秒的额外处理开销，这可以通过直接的HQL方法来避免。HQL对查询的表达也更简洁一些，许多人都会觉得这很吸引人。

简而言之，差别很小，你不需要担心它。