`
acw2000
  • 浏览: 14698 次
  • 性别: Icon_minigender_1
  • 来自: 广州
最近访客 更多访客>>
社区版块
存档分类
最新评论

优化统计查询

 
阅读更多
假设我们现在有两张数据库表,分别是customer表和order表,它们的结构如下:

  customer

  ID varchar2(14)

  age number(10)

  name varchar2(20)

  order

  ID varchar2(14)

  order_number number(10)

  customer_ID varchar2(14)

  现在有两条HQL查询语句,分别如下:

  from Customer c inner join c.orders o group by c.age;(1)

  select c.ID,c.name,c.age,o.ID,o.order_number,o.customer_ID

  from Customer c inner join c.orders c group by c.age;(2)

  这两条语句使用了HQL语句的内连接查询(我们将在HQL语句的连接查询部分专门讨论),现在我们可以看出这两条查询语句最后所返回的结果是一样的,但是它们其实是有明显区别的,语句(1)检索的结果会返回Customer与Order持久化对象,而且它们会被置于Hibernate的Session缓存之中,并且Session会负责它们在缓存中的唯一性以及与后台数据库数据的同步,只有事务提交后它们才会从缓存中被清除;而语句(2)返回的是关系数据而并非是持久化对象,因此它们不会占用Hibernate的Session缓存,只要在检索之后应用程序不在访问它们,它们所占用的内存就有可能被JVM的垃圾回收器回收,而且Hibernate不会同步对它们的修改。

  在我们的系统开发中,尤其是Mis系统,不可避免的要进行统计查询的开发,这类功能有两个特点:第一数据量大;第二一般情况下都是只读操作而不会涉及到对统计数据进行修改,那么如果采用第一种查询方式,必然会导致大量持久化对象位于Hibernate的Session缓存中,而且Hibernate的Session缓存还要负责它们与数据库数据的同步。而如果采用第二种查询方式,显然就会提高查询性能,因为不需要Hibernate的Session缓存的管理开销,而且只要应用程序不在使用这些数据,它们所占用的内存空间就会被回收释放。

  因此在开发统计查询系统时,尽量使用通过select语句写出需要查询的属性的方式来返回关系数据,而避免使用第一种查询方式返回持久化对象(这种方式是在有修改需求时使用比较适合),这样可以提高运行效率并且减少内存消耗。㊣真正的高手并不是精通一切,而是精通在合适的场合使用合适的手段。


N+1次查询的问题

执行条件查询时,iterate()方法具有著名的 “n+1”次查询的问题,也就是说在第一次查询时iterate方法会执行满足条件的查询结果数再加一次(n+1)的查询。但是此问题只存在于第一次查询时,在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。

但是注意:当数据量特别大时(比如流水线数据等)需要针对此持久化对象配置其具体的缓存策略,比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数,以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽,反而降低系统的性能!!!


结果集的使用:
     结果集的使用:list()和iterator()区别
查询方式:
list只能利用查询缓存(但在交易系统中查询缓存作用不大),无法利用二级缓存中的单个实体,但是list查出的对象会写入二级缓存,但它一般只生成较少的sql语句,很多情况就是一条。
iterator则利用二级缓存,对于一条查询语句,它会先从数据库中找到所有符合条件的记录的ID,在通过ID去缓存找,对于缓存中没有的记录,在构造语句从数据库查出,第一次的执行会产生N+1条SQL语句。
产生结果:
用list可能会溢出
通过Iterator,配合缓存管理API,在海量数据查询中可以很好的解决内存问题。
综合考虑:
一般List会填充二级缓存,却不能利用二级缓存,而Iterator可以读二级缓存,然而无法命中的话,效率很低效。一般处理方法,就是第一次查询使用list,随后使用iterator查询。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics