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

那么你为什么很武断的说那种数据就是设计问题？ 做了很多ORACLE,JDE和SAP的2次开发，发现他们的ERP设计都是这样做的，难道他们都设计通不过？

我现在做的系统hibernate肯定用，担不是全用，很多功能就是一个查询而且还不是自己的数据库，还不如直接使用jdbcTemplate

至于那位soho的说


我想说的是，存在即为合理，电信的很多应用oss bss都会出现这种情况，很多表在关联，同时数据量还比较大，主表最少也得是千万级的，更让人气愤的是，数据库还不是你们公司的，而是竞争者的

SQL需要关联10张表，每张表有1000万数据以上
兄弟，虽然本人不是sql专家，但我身边有很牛的sql大拿，如果你身边也有的话，你问问，上面这种描述如果不是设计有问题，是什么？
这种情况下早进行设计上的切分优化了，不会再sql层面做优化，做了也没用。拜托了，切合实际了，俺说的都是实实在在的项目经历，期中不乏和Oracle高手请教过，人家也极力反对这样大表+多表的查询的。

你说的这个情况存在于老系统的对接，但通常发生以后，过一段时间是要变革的。存在即合理，不合理就会被改变，有时候存在时为了等待改变。

我老婆的工作大多数是由于这种表的存在需要。

hibernate不是不适合大系统，应该说，很多做大系统的公司，对hibernate其实研究不深。

hibernate有太多内涵的东西，我首先得承认，我自己只会粗浅的使用hibernate，看过夏老师的深入浅出和hibernate官方指南。

但是看过的知识，能恰到好处的用上，很难。需要经验，需要实践。

而比起ibaits这样的sql封装工具来说，sql上的优势在于，熟悉sql调优的人多，复杂查询使用起来相对简单。

我得承认下，我是不太喜欢使用hibernate的，因为我不够精通，或者说只能算是粗浅入门。在没有使用hibernate多次碰壁抓狂解决问题深入了解的经验之前，大概谁也很难说我就精通hibernate了。

和spring不同的地方在于，hibernate有太多细节了。如果仅仅是粗浅的使用hibernate，我也是倾向认为，其性能确实不佳。

很多做大系统的公司，例如电信，电力，卖油的，其系统历史悠久。

应该说对关系数据库操作的经验是自始至终贯彻下来，积累下来。对系统设计也是以数据库模型为中心而不是对象为中心。这是个设计思路上的根本不同。

另外就是系统风险，应该说，要用好hibernate，是有系统风险的。

罗宾当初有写过帖子，证明hibernate事实上没有性能问题，他也是有实例支撑，javaeye早期就是hibernate做持久层。但是很多电信、电力系统转向hibernate的过程中，能优化到javaeye层次的很少。很多系统仅仅一个登陆过程就比从前jdbc时代慢上许多。

说一千道一万，不熟悉不精通hibernate的还占大多数。

类似jdbc、ibatis这样的sql操作框架易过渡性还是很有吸引力的。

此类系统变更都是一个复杂的替换过程~

所谓的大系统，历史太悠久了。核心的开发人员，熟悉业务的人员，对数据库模型无比精通，他们的思想就是数据库中心论。
俺大概也是受这类影响比较深刻。

hibernate在电信行业也有不少推广，我的感觉，普遍还是比jdbc时代慢不少。

新系统可以用新设计，我看了hibernate版的帖子，力挺hibernate的人无一例外都强调要转换思维，领域、对象、uml一堆上来。

不过对于已经习惯传统mis系统思维的人们来说，在系统业务逻辑上使用对象很容易接受，但是在持久层上彻底对象化就是个云山雾罩的过程——我本人就是这样。

我说了，你不做企业内部，不做ERP，当然看不到ORACLE,SAP.JDE的设计，有条件你可以看看他们的设计，看看他们是否认为你说的那种是设计问题，或者可以和SAP,ORACLE,JDE的系统设计人员交流一下。