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

如果是纯粹的抓数据，抓到业务层做处理，或者少量的写，用Hibernate没问题。但我们有一大半的业务逻辑都封装在Oracle pkg中，这已经不是sql是否能优化的问题了，在业务本身就跟数据高耦合的情况下，多一层ORM不如直接写pkg，况且还能使用PL/SQL进行本地静态编译优化。

  只有设计良好的模型，才能够真正体现hibernate的作用和优点，不过这个对系统设计者的要求很高，而且往往在实际项目中并没有那么充裕的时间去认真做，这往往也是大家认为hibernate性能不高的原因。你系统设计的不好，却非要怪hibernate不行，我都替它感到冤枉。
  另外，关于专业数据库的性能优化问题，一来各种数据库本身的自动优化都已经做的很好了，像之前说的小表驱动问题在Oracle较新的版本中已经自动实现了；另外，如果数据库自己做不了的，比如像索引的指定问题，这个时候也可以使用hibernate的native查询。
  总而言之，那些说hibernate性能不行的人，还是从自己身上找找原因吧，你自己的系统是否设计良好？你对hibernate是否真正了解？不然，你都没资格说这样的话。

不知道你是怎么设计的，是不是也是从数据库反向生成的？

看上去楼主应该没做过什么高并发的系统。

对一个高并发系统来说，数据库往往是整个系统的瓶颈。可以说每一条SQL语句都是优化的对象。
实际操作中，开发人员会拿着可能用到的SQL语句与DBA进行充分沟通。从这一点就可以解释，为什么说Hibernate对DBA不友好（你总不能拿着映射关系去找DBA吧）。

另外一点，Hibernate动不动就做join,对高并发系统来说这是一件很奢侈的事情。往往采取数据冗余的方式。

至于数据库迁移，楼主做的项目应该不少，碰到过多少这样的案例？

当然，Hibernate是一个非常好的东西，对一般项目来说确实能省很多工作量，对高并发系统来说也不是完全不能用，用Hibernate来做简单对象的增、删、改是没有任何问题的。

我通常是先Power Desinger设计模型，然后生成到数据库。然后反向生成到项目中。这只是具体实现的手段，问题的核心还是在设计上。

感谢对我们讨论的问题提出建议，那么恳请这位同志准确的定义一下“高并发”。最好给出大致的数量级别，以及系统反应速度。否则其他人难以通过一个模糊的修饰词汇进行判断哪些情况属于高并发，这样就无助于我们根据具体的情况来选择使用的技术。还记得以前有人告诉过我，mysql可以撑住300w的数据存储，数据量超过300w，oracle的价值就体现出来了。这方面我确实没有经验，因此再谈到这类话题，我还是要提醒对方这是听到的。那么这里所说的 “高并发”到底属于一个级别呢？希望同志能给出一个大致的范围，这样有同类开发经验的朋友才有可能加入讨论，与我们分享宝贵经验，先谢谢了。

PS：我们遇到的项目应该不叫数据库迁移，而是面向的客户会选择不同的数据库，一般是mysql，sqlserver和oracle这三者中，因此我们需要提供这三个数据库下都能运行的系统。

  我不知道高并发的标准是什么，但是我承认我在这方面的经验确实不多。关于join的问题，数据冗余的方式我也用过，不过我认为比较好的解决方案是尽量采用缓存的方式，而不是每次都直接查询数据库。
  数据库迁移的案例我没有做过，不过在做产品的时候，需要考虑到这个问题。假如你在开发产品的时候，用了Oracle，到了客户那，人家不愿意花钱，就想用mysql，毕竟Oracle实在不便宜，这时候你说怎么办？

1.。可以说每一条SQL语句都是优化的对象。
象这样的sql有什么可以优化的：
select c.no, c.name from m_customers;

2 join不好吗？
你的意思，不用join，用多次查询数据库的办法获得数据？

关键不是在技术，而是在人

Hibernate并没有错，错的是使用它的人