Hibernate From 引发的查询性能问题思考

在 javaeye 上几乎到处可见 hibernate 相关文章,计论它的性能问题也不是一天两天了, 在搜索几乎无结果的情况下,发表这篇文章..

 

由于在项目中使用了hibernate,刚开始使用确实很爽,随着数据量的增加,一条查询语句明显让服务器内存直线上升,hibernate 的性能问题也越来越突出,于是开始优化代码,增加了 fetch_size,batch_size,inverse ,lazy 的配制,性能有了些好转,但是问题还是很明显,

 

后来上网查找,网上有人提出可以取消表之间的关联,查询时用HQL通过标识建立关联,但这样一来项目改动太大,后来无意中看到一篇文章里提到使用 Hibernate查询到的对象都会执行实例化后放入缓存中,于是我猜测,问题可能就在这里了.

 

既然查询到的对象会放入缓存,那如果我直接查询某个字段呢? (想到就做,一直是我的一个习惯),测试发现这对系统性能确实有很大影响了,于是项目中的所有hibernate查询语句,都由查询对象改为查询具体字段,

 

这时让我疑惑的是,既然查询具体字段能提升性能,那hibernate 为什么还要有个from 查询呢?少写几个属性名而牺牲性能怎么想都不划算吧..

 

关于hibernate 的一点疑问,欢迎大家拍砖... :D

hibernate的这种机制，增加内存的消耗，相应的增加垃圾回收的频率，一般企业应用，做适当的优化后可以被接受。
优化机制各有差异，带来好处得同时可能也带来坏处：fetch_size,batch_size是为了减少发送语句数量（可能带来多余对象的加载），lazy（减少加载对象的同时，可能增加后续语句得产生），二级缓存（减少数据库负荷的同时可能带来垃圾回收频率的增加）等等。优化的关键针对大批量数据加载，多语句发送得功能进行优化。当然终极优化手段，不玩对象，就象你说的，都改为字段，其实就直接回到jdbc，但这算是一个决策吧，比如你手头上只有一台586的机器，让你用hibernate，还要支持100的并发量，你用吗！？

谢谢 nihongye

考虑这问题时我忽略了 hibernate的使用场合 ..

wcleye  返字段的话，页面怎么引用呢，我这边用 #p[0] #p[1] 感觉很不好啊。

在一个系统中全部使用Hibernate的object navigation、lazy loading特性或全部使用jdbc直接操纵数据库，是两个极端，一边的优点就是另一边的缺点。在这两个极端之间有一段可供调整的距离，调整的办法就包括楼主提到的那些。我们要做的就是在这两个极端之间找到一个平衡点，而要找到这个平衡点颇不容易，这个点是跟应用的类型、规模等密切相关的，需要自己花时间去尝试、调整。或许这是Hibernate比较难掌握的一个原因吧！

我听到一些朋友抱怨Hibernate性能差，或许就是因为在系统中过多地使用了Hibernate的这些特性。其实Hibernate只是提供了这些特性供你选择，如何使用就看自己了：就好象厨房里准备好了各种配料，但要炒出一碟好菜还得看师傅的手艺。

其实lz做得也是一个优化   比如一个表字段很多 确实没有必要加载所有的字段
相反  一个表的数据可能总会被用到  哪就from放缓存

lazy，bathsize，fetch_size，优化HQL，二级缓存，数据库索引，到最终的表分区..这些Hibernate/Database的优化我做下来之后，最后发现Hibernate的性能，比传说中的要好很多很多

优化db再加cache应该差不多了

与二级缓存没关系的全jdbc操作。相信效果会好点。

我记得Query、Criteria接口有个方法叫setCatchable(boolean cachable)

 

Enable caching of this query result set.

Parameters:
cacheable - Should the query results be cacheable?