mybatis和hibernate的区别

一、看法1

一遍看下来，没看到特别满意的答案，作为mybatis支持者我来写几句。
首先是运行速度，hibernate是在jdbc上进行了一次封装，而mybatis基于原生的jdbc，因此mybatis天生就有运行速度上的优势。
然后mybatis开放了插件接口。也许mybatis团队知道自己人少力单，索性把很多功能接口都开放了。不好分页？网上大神写的分页插件多得很；需要手写sql？按注解生成自动生成sql的插件早就有了；还有缓存的插件等等。可以说，只要肯在mybatis上花时间，你会发现orm这一块的所有问题它都有解决方案。这方面不是说hibernate不好，但是我还真没听说过hibernate有插件了。
还有就是对遗留系统的支持。很多系统在设计之初还没有orm思想，现在想“抢救”一下，用mybatis就比hibernate更合适。因为mybatis可以很容易做到不规范的映射对象和规范的映射对象共存，如果这种系统中再需要增加个需要复杂sql的功能，mybatis只需要把sql手写出来，先把功能运行起来后再看看能不能变成自动生成的sql，而对hibernate来说就很困难了。

二、看法2

看了很多的回复，觉得大部分人都有一个先入为主的观念，有意无意都会抬高贬低其中一方。
其实我对两个框架的理解也不是很多，但是在说这个话题前我想先说说jvm的垃圾回收机制。jvm中的垃圾（内存）回收是通过垃圾回收器来处理的。而垃圾回收器是有很多种的，基于不同的算法，也各有优缺点。一般为了达到最优的效率，jvm不会只使用一种垃圾回收器，而是一般根据新生代和老年代的特性选择不同的回收器处理。而某些垃圾回收器更是针对自己的缺点在特殊情况下有其他算法的解决方案。
回到话题上，从设计上来说，Hibernate其实更加灵活多样，这种灵活不是指查询数据时的灵活（也就是Mybatis的优点），而是指在开发效率、便捷度与可控性、可选择性上的灵活，Hibernate本身支持多种查询，通过在不同场景下使用的H的不同查询方式，可以达到开发效率和性能间的一个均衡：在一些简单的查询的地方使用Hibernate的封装的面向对象查询方式，在一些业务复制，涉及到关联表多，数据量大的地方，使用效率最高的Native查询。这样就可以充分发挥不同查询的优点，进而降低各个查询方式的不足。这点其实跟垃圾回收的解决方案和思路上很类似。
Mybatis跟Hibernate的对比，和C语言跟Java的对比有点像，在早期Java内存回收以及效率还没上去的时候，很多人也不会觉得Java好，觉得它慢，可是Java有它的魅力所在，也就是跨平台性，随着后面Java体系慢慢成熟、硬件技术发展起来，在越来越多优秀方案用于解决Java效率问题上后，Java效率的也并没有成为它成为世界变最流行的语言的阻碍。在大部分的业务场景下，应用都可以使用Java进行开发使用，包括现在很多的大型的互联网网站。Hibernate的跨数据库特性和Java的跨平台很像。从C到Java是思想模式上的转变（面向过程到面向对象），最终带来了巨大的成功。从未来的发展上来看，Hibernate的设计思想（ORM）应该是一个趋势。甚至从数据库本身的发展来说，未来也可能出现从关系型数据库到对象型数据库的转变，毕竟现在已经有一些对象数据库开始流行并应用在一些业务场景中了。
而反观Mybatis，它查询数据时灵活和效率、同样也是一个短期或者长期内比较难赶超的优势，就像现在的对象语言虽然为主流，却不能取代完全过程语言一样。
最后我比较赞同一句话，存在即合理。既然两个框架都能成为流行的持久层框架，那么它们肯定有它们各自的过人之处。重点在于使用者如何去根据实际需求权衡选择适合的框架和设计而已。
以上论点可能有很多不准确的地方，因为我开发经验还很少，技术还很浅薄，对很多东西的了解都不够多与深入，个人观点，不对欢迎指正。

三、看法3

刚刚spring-data-jpa 用就遇到两个问题：1，数据的分表用不了（select * from user_?%10 分了十个表，按id取模来决定查哪个表） 2.自带的过滤查询只支持常规的大小比较，不支持在字段上的运算（where propery*3=? 或者 propery&?!=0 ），感觉好不灵活，有大神指导吗

四、看法4

说Hibernate性能问题的，没有用Mybatis手写sql来的快的都是Hibernate的菜鸟。你自己不会弄不能说框架不行。在单数据库下会用Hibernate的都知道，Hibernate性能远远高于手动sql。这个结论是Hibernate之父Gavin King也是在jpa规范的制定者很早拿出来宣传的重点。在国外的java圈，这个观点大家都是默认。否则当年Gavin King也进不了sun。也不可能在java世界有如今的地位。
Mybatis只是一个半orm产品，除了灵活好学外各方面都不如Hibernate。用Mybatis之所以能流行起来有两个原因。适合初学者意淫是基础。第二。是bat喜欢使用。之于为为什么bat喜欢用是因为，以bat的流量已经到了要自己开发自己数据库以适应大规模集群的阶段。比如：阿里的核心数据库就是在开源的mysql上改过的。这种改过的数据库，Mybatis手写sql为核心的框架有天生的优势。
Hibernate全自动orm的优点在于会用的人拿它做项目，快速，高效，高度解耦。在项目开发，数据库结构不断变幻阶段，不知甩Mybatis几条街。但是，也是因为它全自动的优点，在计算机集群需要大量跨数据库事务的环境下是不如Mybatis灵活。
Mybatis只是一个小玩具，它有的功能，Hibernate也有。Hibernate也有自己拦截器，甚至可以在它生成的sql里像Mybatis加入自己的东西的。不过，一般没人，国内也没这类的教程。因为，这么用就失去了用Hibernate提高开发进度的本意。
单数据库下Hibernate无敌的存在，有怀疑的都是外行。集群下优点变缺点，但是，不是不能解决google有一个开源项目可缓解这个问题。只是比Mybatis复杂很多而已。所以，Hibernate特别适合那些有技术实力，项目处于开发期，数据层级不稳定的时期。
之于，数据量大了以后，真正上开始上集群。Mybatis这个小玩具开始上台的时候，其实，数据库技术其实已经不是核心，大数据跟no-sql会更好地解决问题。这一时候的db层，所有人的精力基本上也在hadoop跟spark上了。只会Mybatis在有点规模的互联公司，永远走不出非主流，小三的命运。

五、看法5

我的经验是主要看这3个指标来确定，第一个因素权重最大。
1、数据量、有以下情况的最好就用MyBatis
如果有超过千万级别的表，
如果有单次业务大批量数据提交的需求(百万条及其以上的)，这个尤其不建议用hibernate
如果有单次业务大批量数据读取需求(百万条及其以上的)
2、表关联复杂度
如果主要业务表的关联表超过20个的(大概数量，根据表的大小不同有差异)不建议用hibernate
3、人员
如果开发成员多数不是多年使用hibernate的情况(一般开发水平评估)，建议使用MyBatis

六、看法6

Hibernate理念不错，完全的ORMapping，MyBatis只是个SQL Mapper
理想和现实是有差距的，把不是object的数据库结构映射，是一种leak abstraction
Hibernate用来做学校项目级别的不错，真正的项目一般都用mybatis，毕竟控制能力，调优成本更重要

hibernate的门槛比较高.老实说,真的会用hibernate,并且能在产品里驾驭的人很少很少.

补充一下，hibernate的sql是可控的。调优也和sql没有什么大区别。觉得关联查询控制不住的，是因为不太会用。

Hibernate写好实体类后，基本不需要做太多东西了，但是比较麻烦的是它的关联配置，很多时候是个难题，在就是查询语句自动生成不够灵活和高效，对一些dba不太友好。mybatis可控性比较好，你说的实体和映射以及配置文件可以通过官网提供的工具自动生成，学习成本相比hibernate要低很多。另外spring推出的spring data jpa跟hibernate相结合后虽然能解决查询灵活度问题，但是相对于mybatis来说还是不方便，建议你使用一下它们，自己就更能体会出其中的差异，从而在项目选型时，更贴近实际。

hibernate在实际项目开发中，前期很顺利
后期每个人都恨不得杀了hi

七、看法7

Hibernate没有你说的这么简单和方便，如果是很简单的增删改查，而且不牵涉到多表关联，Hibernate会是好的选择，但是这样的情况很少吧。
我觉得HIbernate的有一下几个严重的缺点：
1. 多表关联等比较复杂，使用的成本并不低
2. 效率比较低，在大型项目中很少会使用到它，因为sql都是自动生成的，不太好进行人工的优化。调优需要丰富的经验，这些经验可能是需要被坑过很多次才知道

等等吧

八、看法8

hibernate只是简单使用过，mybatis的源码年前后无聊的时候写了一遍注释/通看了一遍(80%)。
在下认为mybatis会有更强的掌控度，你可以控制sql，而不是hibernate那样使用hsql。你几乎无法预知生成的真正sql是什么样，多么烂。。
这个优点前期并不明显，尤其是表少，表关联少，数据量少的时候，因此这个阶段hibernate会更方便，但是一点复杂度到了一定程度，那mybatis的优越性就就来了，自己写sql，可控度非常高。效率也不会因为无法预计的sql而被拉低(不排除人为因素)。。
当然还有缓存啥的。。具体hibernate不了解，不做比较。
个人觉得仅从控制度和个人控制欲这一块，我就选择mybatis。
为什么我不把能掌控的东西都掌控在我自己的手里？

使用hibernate1.写复杂查询比较费劲2.多表关联如果运用不恰当很容易造成性能问题 3.hibernate学习成本高,个人感觉 相信不少同袍有同感的 而iBatis直接写sql方便,学习成本低

个人觉得多表关联（20个表以上）最好不要选择Hibernate,维护成本比较高，高并发的程序最好不要选择Hibernate。如果你熟悉Hibernate的使用，企业级的应用选用Hibernate比较实用，开发周期短。我觉得说Hibernate没有Mybatis灵活有点扯，毕竟Hibernate也可以写hql语句。到底怎样选择还是根据具体项目具体使用。

那些说Hibernate不好用的只能说明他还不会用Hibernate，Hibernate和Mybatis相比只能说一个是巨人一个是小屁孩，巨人力量强大，小屁孩机灵。性能问题都是扯淡，如果你会使用Hibernate,开发成本绝对比Mybatis低，性能误差1ms以下，呵呵，1ms时间基本上算不了什么，有些人还把Mybatis吹的那么高。

小弟现在在学习Mybatis，感觉Mybatis比Hibernate不好用，写个代码麻烦的要死，弄个分页还要装插件（也不知道兼容性怎么样），至于这个Mybatis generator现在还在研究（怎样把分页嵌入其中）。其实hibernate用好了性能其实不会太差，毕竟有缓存撑腰，其实Hibernate可以像Mybatis一样，把sql写在配置文件里面。

Hibernate 的灵活性没有Mybatis好，而且Hibernate的学习成本相对于Mybatis要高。

你们都忽略了一个要点：Hibernate/JPA 要长时间占用Connection，而且一不小心就写出个长事务，而MyBatis可以每条statement用一下Connection就还回去。
随借随还的模式更适合大规模高并发程序。
至于查询性能，如

所述，无明显差距。批量操作等场景可直接写SQL。

我两种都在百万级PV大型互联网项目使用过，Hibernate更好用，MyBatis更适合与DBA合作，两者性能都OK。
还有个小众的Ebean ORM，综合了两者优点，效仿了RoR的Active Record，也很不错。