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

  关于对hibernate的看法，由于每个人的经验和水平的不同，肯定有不同的见解。所以关键不是它到底好不好，而是它对你到底有没有用，合不合适。你sql写习惯了，也很好；你喜欢用ibitas或者toplink什么的，那也无所谓；如果说你就喜欢hibernate，那握个手，可算找着组织了。从关系型到面向对象之间有着太多需要解决的问题，它不是银弹，不可能解决所有问题，所以，还是要辩证着去看。
  性能这个东西，影响因素太多，不是hibernate所能完全解决的问题，比如系统的架构设计，服务器的配置，数据库和JVM的内存配置，数据库表以及索引设计的合理性，缓存的使用等等。我只能说，你会用hibernate的话，它绝对不会成为你系统的性能瓶颈，相反，通过良好的设计和缓存的应用，它能够表现出很好的性能。写sql还有人写的很烂呢，你总不能说sql性能不行吧。

用hibernate开发，必须得有sql基础，你之前发的贴说不用了解sql就用hibernate是个大笑话，懂sql才能写出好的hql。

麻烦你想强调用hibernate取代jdbc，麻烦给个精明的比较，跟我们这些喜欢用jdbc的迷途的人说说jdbc的恶劣的不可忍受的地方然后用hibnernate是如何解决的？
不要总整个套套理论来说明。

原谅我这里的较真，因为“高并发”，“大项目”这些词实在太雷人，很容易被一些人作为把柄恶意引用，然后就会出现一群人因为对这些名词的理解不同而引发无谓的争吵，实际上，只要稍微用定语划一个范围就可以免去很多麻烦，毕竟群众的眼睛是雪亮的，只要讲的清楚大家都能明辨是非。

其实在下一直对千万级数据，分库分表的应用心驰神往，可以一直无缘得见，不知道这种项目里的组织机构是如何划分的，是否由dba前期一次性完成所有设计和封装工作，剩下的只要外围应用去调用就可以了。感觉对外部应用的限制很大，在这种项目里玩岂不是很无聊，每天的工作只是调用封装好的东西而已。

想想sns项目 访问量和数据量
是否由dba前期一次性完成所有设计和封装工作 ----我是很期待这样 但是现实情况是 完全自己做
当然完全靠数据库肯定不行的 这就是其他方面的问题了

我和楼主的观点一致，没有包揽一切的东西，hibernate也不例外，hibernate对数据操作的封装，让开发之前就可以在一个地方统一的对数据操作进行整体规划，我认为这个很重要

就像上面有人说，高并非，其实有多少系统有那么多高并发，基本上整体规划好的话，并发的要求一般都不多，从整体很好的规划系统真的会避免很多不必要的东西，呵呵，务虚了

企业应用，例如ERP,物流系统，高并发不是问题，问题在于及时性，你对某个东西做了修改，其他地方要立即看到。所以某些缓存设计不大适合企业系统。

你说的情况的确需要优化。但是你区解我的意思了。我想说的是sql本身并不需要那么被关切，以致于要每条都让DBA看。
到少你不是DBA吧。

你说的情况是和需求有关的。如果这个sql变成这样：
select m.name,m.id from m_menus
你还认为需要你说的优化吗？

我没有做过 这里讨论的 “高并发项目”。 但的确做过一些性能调优的工作，一般来说，软件的性能问题，是可以应用80 20原理的。也就是说，很可能软件的性能问题只来自已20%代码部份。因此，只要找到热点，就可以从多个方面来解决性能问题。

目前我做过的软件，还是功能性需求占第一位。性能问题，一般来自于对数据库的多次访问。

我就纳闷了，ORM和数据库模型本来就是一致的东西，既然你说为了高并发会做一些特殊的设计，那同样的实体模型模型也是可以针对高并发做特殊的冗余设计的。
你不想用join，那就告诉ORM不要用join，用你所期望的查询，这些都是你设计层面的东西，怎么会怪到hibernate头上来了呢？

如果说数据库迁移，这些东西你选择什么样的技术已经和这个帖子无任何关系，但是只要你说高性能，高并发hibernate不适合用，那就贻笑大方了。

现在最大的问题是开发设计人员思路混乱，用做网站的思路做企业系统，用做企业系统的思路做网站。

我认为hibernate真正的尴尬不是性能问题，而是他最初定位的ORM，面向对象。
他期望大家忽略关系型数据库的现实，去构造一个面向对象以及领域模型的一个美好蓝图。
但其实结果不容乐观，在依然是关系数据库横行的今天，光靠hibernate可能很难扭转这个格局。