我一直在读一些水壶,但我仍然感到困惑.为什么？因为你提到的差异与绩效无关.它们与易用性有关.(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并且它不会更改表的别名.
我很困惑.如果有人知道主要原因,请帮助我们.谢谢
总的来说,如果您使用HQL或Criteria来创建最终的SQL,那么在后续版本的Hibernate(版本3.3及更高版本)中,性能将不会有太大差异.
要对此进行测试,您需要在HQL和Criteria界面中创建代表性查询.然后从逐步旧版本的Hibernate中记录生成的SQL(可能使用Maven来允许快速版本更改).您会注意到,随着Hibernate版本的减少,您将看到最终SQL中的更改.
尝试在代码中优化HQL和Criteria之间没有什么意义,因为绝大多数时间丢失将在应用程序和数据库之间的网络流量中.当然,这假设您有一个结构良好的查询,不需要超过一亿行或类似的多个全表扫描.
被引用的博客试图揭穿神话,所以要小心你不要把标题脱离背景(强调我的):
9)"Hibernate很慢,因为Criteria接口生成的SQL不一致"
有人说,如果所有查询都是通过Criteria接口而不是直接在HQL中构建的,那么Hibernate也会产生性能损失.该论点假定这是因为每次执行查询构建器代码时(例如在DAO中),Hibernate都会为查询中的表生成新的别名.在Oracle中,这意味着每次运行基于Criteria的新查询时,数据库都必须创建QEP - 查询执行计划 - 因为它无法匹配已在其缓存中为其提供的SQL.创建QEP可以利用它需要对甲骨文的SQL语句响应时间的30%,因此对于相同的(但别名)的SQL语句的第二和后续执行过程中的标准有一个内置的开销,使得它比直接HQL慢50%.
Hibernate 3.3及更高版本不再是这种情况.如果它真的是真的有疑问,因为Hibernate团队肯定会尽可能地创建最佳SQL.独立测试表明,在重复调用跨越事务之后,Criteria接口会生成相同的查询,这相当于在负载下运行应用程序.在每种情况下,查询保持相同,因此可以由Oracle缓存.
但是,有一点是事实,因为每次使用Criteria接口都需要创建查询,而使用HQL中定义的命名查询允许在应用程序启动期间进行预编译.但是,这需要一些观点.使用Criteria界面创建简单"之间"查询所花费的时间在普通PC上大约为3毫秒.在应用程序中嵌入HQL不是一个好的选择,因为它不会导致使用不同的提取策略维护查询的直观机制,因此基于Criteria的方法被认为是两者中更好的方法.
因此博客基本上指出,主要区别在于Criteria接口可能会引入几毫秒的额外处理开销,这可以通过直接HQL方法来避免.HQL在查询表达方面也更为简洁,许多人会觉得很有吸引力.
简而言之,差异是如此之小,你不必担心它.
| 归档时间： |
|
| 查看次数： |
7041 次 |
| 最近记录： |