关于mybatis和hibernate的困惑

Question

• 由于java视频里以前好多都是SSH。但是在实际工作中没见过用hibernate的，基本都用mybatis。

• 我有一些疑问：

• hibernate碰到什么样的业务会变成致命的弱点，都说hibernate效率低，能否举个例子（例如同一个查询用mybatis查询耗时1秒，用hibernate查询耗时10秒）

• 可能是有部分人遇到了hibernate的瓶颈，但是这部分人的业务量我觉得，不是大部分使用hibernate的人都能遇到的。一般的小项目，不超过100个用户，这样的项目综合考虑的话更适合用mybatis还是hibernate？主要从开发效率上来说的话。为什么？

谢谢

Answer 1

hibernate适合于都是单表的增删改差，开发效率很高，可是一旦业务扩展或者当初db设计不好，需要连表查询（因为hibernate的思想是对表的类化，但实际生活中要做到完全的类化在一个项目刚开始的时候是不容易做到的）不同的结果再加上删选匹配的话效率就会下降（除非你写sql，但是这样一来还不如一开始用mybatis），尤其再遇到大数据量，效率成倍数下降。不超过100个用户？，这里的数量级不是按单表算的，单表如果超过一定数据量也不是简单选用hibernate或mybatis能解决的，只能说如果用mybatis的话比较好改而已。就我经验，如果涉及大量连表查询且业务复杂的时候（通常项目到最后都是如此）最好用mybatis，简单的还是hibernate快一些（开发效率）

Answer 2

hibernate学习成本比较高，但是j2ee里头有JPA规范，学习规范也还可以。mybatis就相对来说简单，容易上手，可控。hibernate学习成本高，过度面向对象，难以调优。至于使用的话，看个人了，对于toB或者toC的应用比较偏向mybatis，但是对于做管理后台这种，hibernate就可以

Answer 3

下面的回答说的都挺好的，一是MyBatis学起来简单，二是灵活，直接写SQL易于掌控，至于性能都不是什么重点，开发效率、可维护性什么的比性能要重要的多。

Answer 4

hiberbate是用java对象拼sql，mybatis是直接写原生sql。前者开发一时爽，(修改)维护火葬场；后者需要对sql知识有一定了解(相比前者)，如果公司有DBA的话，他看原生sql比看java代码要直观得多。至于性能什么的大部分情况下都不用考虑(真要考虑的话可以去搜一下近年来有些人讨论过的“去ORM”)，最重要的是可维护性可维护性可维护性。

Answer 5

hibernate、mybatis都只是对JDBC的封装，程序性能好不好，主要还是看SQL写得够不够优秀，DB设计是不是合理，当然hibernate不少SQL是用程序方式实现的，如果两个框架都很精通，使用起来性能上差别应该不大，那么问题来了，hibernate封装程度过高，想精通其实是挺困难的，mybatis则只是jdbc的简单封装，学习成本较低，而且hibernate很多场景下将sql封装起来了，如果不是特别精通的话，有些时候写出来的程序会出现预料不到的情况，mybatis则因为较简单，也没做太多的事，所以程序运行结果通常比较容易预料到可能出现的问题。两个框架其实设计都很优秀，个人使用习惯反而更重要，习惯于mybatis的人，一般很难会再切换到hibernate的，反之如果真正精通hibernate的人，应该也不会刻意去使用mybatis(个人愚见)。

Answer 6

实际工作中都使用Mybatis基本上并不是基于性能或者可用性上的考量，而是基于个人习惯。像我们这些老程序员，写SQL习惯了，不写就难受。相比之下过于自动化的hibernate会让我们感到恐慌。仅此而已。

Answer 7

学习阶段使用过，hibernate 个人的感受是封装的太死了。很多时候感觉带来的不是方便，而是我要为了“配合”这个框架做一些看起来不必要的操作。

Answer 8

业务量比较小的话，就看你个人哪个比较熟练了。都可以。没必要为这个纠结。mybatis的灵活性要高些，给开发人员更多自己实现的空间。hibernate的关联应该是稍慢一点的原因。

Answer 9

知乎上也有类似的问题。看到高票的回答大致就是说，hibernate比mybatis掌握难度要高一些，对sql的控制弱一些。

Answer 10

mb sql写到xml里面不也需要解析么，效率也高不到哪里去吧