为何每次问到传统sql如何调优就没人回答？另附几则hibernate性能优化实践

hibernate没有让你不去关心这些东西，而是让你在开发的时候可以用这个工具去提高效率，但不是说让你不关心这底层的东西。

开发效率提高，业务问题很容易解决了，然后让你有更多的精力去关心底层的东西：比如性能问题等等。

现在有一帮子这样的人出来跳，以为hibernate是可以让自己偷懒不用多努力学习底层的东西就可以混饭吃，结果发现事实并不是那样，认为仅仅是看起来很美，结果还得让自己关注底层的东西才能解决性能问题，所以就气急败坏的宣布：hibernate不适合用来做大项目开发，不适合做高并发开发。

对于这帮子人，我奉劝一句：你在家丢人我不管，但是出来献丑那就是你的不对了。

我很赞同你的观点。

对于某些人而言，他希望快速上手，这个使用动机是良好的。
希望在整个团队当中做到跟大家水平同步，leader也很乐意，框架化便于管理嘛。
而且在小型团队当中也能取得一定的效果，但接下来问题来了。
如果没有经历过早期的裸sql开发时期（或者说没有一点SQL基础，数据库基本调优）。仅仅期望把它当成一个快速上手的工具，并且希望它取代并且绕开SQL，
那结果自然是失望了，这里就会出现所讨论的性能问题。

其实我觉得，hibernate的性能问题就象 c语言和java语言的关系一样。
c语言速度快是公认的，为什么现在大家都在用java呢？ 原因很简单，是因为java的一点性能损失代来了java语言使用上的简单和方便。而这点性能损失是可忽略的。

jdbc和hiberante的关系我认为是一样的。hibernate代来的是业务逻辑的方便表达，损失的是一点可忽略的性能。

但是hibernate是以面向对象为基础的，而现在大多数项目是以 失血 模型 方式开发的。代码本质上是对业务逻辑的过程化描述。而hibernate的内含确是要支撑领域模型的，需要一些学习成本。因此我认为，以过程化为主的软件，在人员水平还不能理解hibernate的内含时，是不宜使用它的。

我想这个主题要讨论的问题是与Native SQL相比Hibernate有没有性能问题，而不是能不能用Hibernate的问题。

我不知道是我误导了这位仁兄还是这位仁兄误读了我的意思。

我想表达的是性能上及数据操作层面的优化上确实是Native SQL比Hibernate占优势。

没人说高并发系统一定就不能用Hibernate。
就像前面有人说的，性能因素是多方面的，优化的途径也多种多样。

其实很简单。28原则，用hibernate处理80%简单的增删改以及简单的后台操作，剩下的20%复杂查询应该想办法交给sql解决。

指望hibernate解决所有问题，就需要非常深入的了解hibernate才行，再学一套复杂的hql，与其这样还不如native sql来的方便。sql在学校所有人可都学过一遍的，学深点更容易接受。

我没有误解你的意思，反而我觉得我捉住你的本质问题所在， 重点是这个：



细节总归是体现在问题最本质所在的，所以我喜欢捉住你们每一个细节来看，从这句话来看，我觉得你还是没有把hibernate用活，还是很教条式的使用它。以及因为这个教条式而导致后面你所谓那句牵强而附和的言不由衷的概括：


我只是想告诉你一个本质：hibernate就是用native SQL来解决问题的，掌握好了它，你几乎没感觉到ORM和native SQL有多少差别。

SQL需要关联10张表，每张表有1000万数据以上。。最少。。需要进行复杂的查询。需要用多很多ORACLE特有的函数..写完的SQL在100行以上。。

不认为hibernate能够适合这样的环境

这个复杂的统计查询需求你就用SQL查询好了，难道你不知道hibernate也有SQLQuery吗？

萝卜白菜各有所爱。
Mark！

听课，说的都有道理。

不会用sql的人要想用好hibernate，基本上算是小概率事件吧。
会用sql的人要想用好hibernate也不是一件容易的事。

你这么一说，我个人感觉，hibernate的特点在于单体个增删改查上么？

我认真地看完了前面的帖子，老实地说，楼主对大规模，高并发的项目没有一个明确的印象，或者说没有接触到过。

在税务，银行等系统中，内部系统或者外部系统，hibernate是不适用的

我自己也学习过hibernate，上手很快，做个小的demo出来也很好看。但是就是学习曲线不够平滑。