|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-22
性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
godson_2003 写道 对于大表的N+1问题 我们在设计数据库的时候为什么不适当的冗余呢？
产品表完全可以冗余产品分类 解决办法后很多 支持你的想法，冗余设计其实是一个博弈的问题，有时我们不能太技术，总是考虑要做到没有冗余，现在硬盘又不贵，相比连接表造成的性能降低，还不如冗余设计呢，就说产品表，产品类别的改动一般都不大，即便产品再多，相比产品的查询和增加，类别的变动几率要小的多。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
楼主对hiberate的调优方法很不错，也正是我工作中常用到的方法。应该成为每一位hibernate使用者知识库中的一部份。不过，现实情况是很多人对这个不了解......
|
| 返回顶楼 | |
|
发表时间：2010-03-23
最后修改：2010-03-23
确实hibernate性能不好是听来的...
我技术水平很低..平时工作,hibernate最多用来做增删改查...还是单表 稍微复杂的查询就视图...表多就物化视图... 开发中根本没遇到过性能瓶颈... |
| 返回顶楼 | |
|
发表时间：2010-03-23
tibetjungle 写道 性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 什么样的产品需考虑到你说的这些技术呀？ 你说的技术我不太了解。但是，大家都知到 汇编、c、java 的性能关系和使用特性。 我感觉你说的内容和这个很象。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
最后修改：2010-03-23
lizhilin 写道 我遇到过的 针对mysql 优化sql
use index语句hql不支持 需要自己扩展 为了性能 有些复杂的写法 只能使用原生sql 二级缓存可以满足一般需求 但对于查询缓存没找到很好的扩展机制 很多时候为了性能 查询缓存要自己做 这位仁兄提出的问题很尖锐，hibernate确实搞不定这种特定数据库的专有用法。只是这类建立在专用数据库语法上的表设计也是需要对这个数据库很熟悉的人才能搞出来，所以才被称作DBA啊，这其中训练开发人员掌握这种专有数据库的sql用法的学习曲线是否会很高呢？而且这类完全依赖数据库的表设计，万一客户出现了更换数据库的需求该如何应对呢？我们这边遇到的情况，mysql，sqlserver，oracle都是有可能用到的，解决的方案该不会写三套实现吧？这方面确实不熟悉，还望多多指教。 反过来说，如果是做网站，或者对象客户群只会使用一种数据库，那么这种设计方法绝对可以极限的挖掘数据库的潜质，飞速提升效率，hibernate在这一点是绝对比不了的。 moyue 写道 godson_2003 写道 对于大表的N+1问题 我们在设计数据库的时候为什么不适当的冗余呢？
产品表完全可以冗余产品分类 解决办法后很多 支持你的想法，冗余设计其实是一个博弈的问题，有时我们不能太技术，总是考虑要做到没有冗余，现在硬盘又不贵，相比连接表造成的性能降低，还不如冗余设计呢，就说产品表，产品类别的改动一般都不大，即便产品再多，相比产品的查询和增加，类别的变动几率要小的多。  理论和现实还有是差距的，现实我们常遇到的问题是，项目太紧，没时间详细设计表结构，拿来单据就要照着上面的样式“搞”数据库，连设计过程都省了，这么着急做出来的东西基本没考虑到必要冗余，结果后期出现性能问题就要继续调整咯。恐怕在座的做业务软件的同志，很多都有这样的经历吧？
flootball 写道 还在考虑Hibernate性能啊！
现在都考虑直接走磁盘了。这样可以去掉日志，锁，认证, 索引文件可以大大的减少。 个人感觉，直接走磁盘的方法估计一般人都不会用到，业务系统里更多考虑的是业务逻辑和事务性，这个方向应该不需要继续展开了。 tibetjungle 写道 性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 关于有效索引的问题，容我再去查证一下，多谢指出。 PS：补充一下“小表驱动”在google上搜索到的结果： 1。oracle9i中查询的情况，需要把小结果集放在前面，大结果集放在后面，这样可以使用小表驱动查询，提高查询效率。oracle10g中会自动选择小表，所以无需在写sql时注意表的摆放位置。 2。mysql据说会自动使用优化器在查询时选择小表驱动，所以也不需要考虑sql语句中表的位置。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
tibetjungle 写道 性能问题不光是你说的1+N的问题，1+N只涉及磁盘IO次数或者缓存，Lazy load也是磁盘IO次数问题，但每次做I/O出问题了，比如最有效的索引没有用，多表查询时驱动表不是小表，Hibernate怎么使用最优索引，怎么用小表驱动查询？但用原生sql就可以，这就是原生sql的好处。
hibernateb不是银弹，原生sql也不见得会降低生产率。 这我就不懂了，驱动表你sql可以自己选择，hql你也可以自己选择。 这又有啥区别呢？ 最有效的索引没用，这个问题从两个方面来看，如果你必须强迫用某个索引，那么这里你可能只能选择hibernate的sql查询了，否则，那就和你写sql查询没有任何区别了，你该去查查有效索引为何没被使用的真正原因。 正如我说的，hibernate不能解决所有问题，这些问题你就特殊处理好了，一点问题都没有，甚至连皱眉头都没必要。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
深有同感啊。在我负责的产品中一直使用hibernate，感觉也挺好，但也出现了不可避免的性能问题，然后就收到了公司其他的所谓懂技术但不干技术活的同事的攻击。他们总说hibernate的不是，却又说不出来到底哪些地方不好，我猜也就是在网上看了一些不会用hibernate的人发的负面贴子。他们说外面的大项目和产品没有一个会用hibernate来开发的，都是基于最简单的jsp+jdbc+javabean的组合。和他们争论了好久，兄弟我迫于压力，后来的项目也只好自己封装了spring的jdbc，模仿hibernate的api实现了一个泛型DAO的基类，算是抛弃hibernate了。另外一个原因是我的手下对hibernate的理解和使用都不够深刻，滥用hibernate的api，我的人手本来就不够，所以也无法控制。如果公司给我绝对的决策权的话，我还是会毫不犹豫的选择hibernate的，实在太喜欢了。
个人建议：我们针对本贴建一个群吧，专门讨论hibernate的问题，然后大家一起起草一篇文章，用事实说话，来验证大家对hibernate的各种看法。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
hibernate用的好用的优化是比较难的事情。。。
比如楼主说的几条，初学者难以做到。 而普通的sql调优，大概程序员都有积累一些心得，即使你不会，把sql提取出来给专门的人做也很容易。 而hibernate的高手相对就没有sql高手多了。 |
| 返回顶楼 | |
|
发表时间：2010-03-23
技术风险，就是这样。
产品化的项目很有必要上hibernate，项目化的，那么就应该考虑下实际情况。 基本没有hibernate做不到的事情，但是想做好很难。 从各个公司的知识积累来说，对数据库的构造、sql的优化都是有相当丰富经验的。对j2ee这块就未必了 |
| 返回顶楼 | |
