理论性问题：hibernate应用在复杂情况可能会大大降低性能吗

Question

不要猜测，还是用起来再说。当发生问题时，我们去解决它就行了。 而且hibernate允许你直接写SQL,人家留下了后门的。

Answer 1

个人认为，Hibernate的缓存机制，在大型应用中应该提高系统性能才对。
不过这也只是我个人的看法，1楼说不要猜……

Answer 2

缓存jdbc也有，处理完所有再提交不然回滚，也算是缓存机制吧。

Answer 3

有熟悉Hibernate的前辈近来谈谈嘛...

Answer 4

再用的时候的却碰到过运行速度慢的问题
不过那是设计上的原因
他设置了一个计数的view来读取某些关联的运算完后的结果
结果去读那个view的几个页面，每次都要进行一大堆的hql。
最后改成直接写sql了
所以再表多，关联多且烦的情况下，不如直接写个sql

Answer 5

首先明确一点，用hibernate确实要比直接用jdbc慢，正常的情况下应该是稍慢一点，但在可以忍受的范围之内
具体原因可能是：
1.hibernate最终还是要通过jdbc去访问数据库，所以使用hibernate也就相当于在调用jdbc之前和之后多干了一些活，当然就要慢上一点了
  JDBC：发送sql到db -> 接受db返回的数据 -> rs.next()该干吗干吗
  hibernate:解析hql生成sql -> 发送sql到db -> 接受db返回的数据 -> 根据返回的数据构建对象 -> 把构建出来的对象组装成List返回(使用query.list()的时候)
  头尾都多了点事，自然要慢上半拍了。而且，不难理解，如果表多，关联关系复杂，头尾多出来的事所占用的时间也会越多
2.hibernate可能会使用反射来操作类，反射其实性能是比较差的，尤其在老版本的JDK中，据说现在已经改进很多了
3.也许你只要更新整个类中的某2个字段，但你用hibernate只能更新整个类(即所有字段)，或者你只需要查询某3个字段，但却得把整个类查询出来
4.其它的，暂时还没想到，大家补充啊不过，就像楼上有人说的，hibernate允许自己写sql语句
所以，如果你发现某个hibernate查询性能特别低的话，可以自己写sql直接查

Answer 6

   hibernate有一级缓存和二级缓存用好了速度也不错

Answer 7

hibernate比较流行的性能问题就是n+1问题
这个不能怪hibernate,是程序员太懒了,其实可以自己搞定的,
hibernate就是api太多了,上手容易深入难,多对多的问题除了麻烦点也没什么

Answer 8

人家说“hibernate用起来是方便，但在大型应用中要慎用，一不小心就会降低系统的性能”。你师兄说的是正确的。我们有一个项目深受其害。

Answer 9

这位朋友,能给解释下hibernate里的n+1次查询问题么?

Answer 10

Hibernate是一把笨重的宝刀,不是每个人都舞得动的。 如果舞得动,那的确是把宝刀。

Answer 11

Hibernate 一点都不好,多表查询时.如果一个写不好,就会...呵!!!!!
我现在自己写了一个类Hibernate 的功能的东西,一样很好用,差键是有些Hibernate的功能你用不到,也不了解是什么意思,后期的研发.就会出现很多风险不可控制的问题,如果你是自己写出来的.那么风险就可控.

Answer 12

就是因为延迟加载的原因,本来一条sql查出了n个对象,但是你调用每个对象的关联对象,则会执行单条sql n次.
一共执行sql数是n+1次,这个太影响性能了
解决方案
1.左连接(程序员用了hibernate一般连左连接都懒得写了)
2.二级缓存(具有一定的局限性,要求实时性不高的数据)
最好,楼主还是百度吧,查询hibernate性能调优就好.

Answer 13

hibernate 绝对是一把宝刀，主要还是在于使用宝刀的人，会不会用了解不了解这把宝刀，性能绝对不是问题，
    
     性能主要注意的地方
         
           1：一对多和多对多关联要用延迟，和inverse，尽量少用级联更新
           2：查询多用左连接和左迫切连接
           3：数据库设计的粒度要高另外hql是非常好的查询语言可以替代sql，目前我做的统计查询都是用的 hql，希望大家还是多了解hql 你会发现你可以抛弃sql的