1.概述
Spring Data JPA可以理解为 JPA 规范的再次封装抽象，
底层还是使用了 Hibernate 的 JPA 技术实现。
MyBatis本是apache的一个开源项目iBatis,
2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis 。
Mybatis：着力于POJO与SQL之间的映射关系。
2.性能
由于 Hibernate 比 MyBatis 抽象封装的程度更高，理论上单个语句之心的性能会低一点
（所有的框架都是一样，排除算法上的差异，越是底层，执行效率越高）。
但 Hibernate 会设置缓存，对于重复查询有一定的优化。
所以，从整体的角度来看性能的话，其实两者不能完全说谁胜谁劣。
3.与 Spring 的集成
Spring 以及 Spring Boot 官方都没有针对 MyBatis 有具体的支持，
但对 Hibernate 的集成一直是有的。
但这并不表明 MyBatis 无法与 Spring Boot 集成，
毕竟现在互联网企业，还是很流行使用MyBatis 和 Spring 。
MyBatis 官方社区自身也是有 对 Spring / Spring boot 集成做支持的，
所以在技术上，两者都不存在问题。
4.编码
Hibernate的开发难度要大于Mybatis。
主要是由于Hibernate封装了完整的对象关系映射机制,
以至于内部的实现比较复杂、庞大，学习周期较长。
Mybatis 主要依赖于SQL的编写与ResultMap的映射。
5.数据库的扩展性
Hibernate与数据库具体的关联都在XML中，
所以HQL对具体是用什么数据库并不是很关心。
Mybatis由于所有SQL都是依赖数据库书写的，所以扩展性，迁移性比较差。
6.老外喜欢JPA的原因
第一点：很多老外对Mybatis的认知还停留在iBatis阶段：
实际上在Mybatis的应用场景里面，开发者要的就是自动封装，
把sql查询结果转化为指定的java对象。
这个在iBatis阶段，需要开发者自己定义大量的xml配置，
去指定数据库表字段与Java实体类之间的关系。
并且，对于每一条sql，都需要在xml中写相应的语句，
虽然有代码生成器，带开发量还是不小的。
但Mybatis发展到今天，已经非常完美地做好了自动封装数据对象这件事，
支持的插件也比较丰富。对于常见的增删改查，也不需要自己写一行代码，
这已经无限接近于Hibernate的能力了。
第二点：喜欢OOP、DDD，认为写SQL不优雅
用jpa的核心是让我们关注对象建模，而不是关心底层数据库映射。
只有你在考虑数据和行为在一起的充血模型、贴身职责，聚合根状态变迁，
值对象不变性的情况下，你才会发现jpa给你提供了很多便利，根本不需要关注底层存储模型。
在复杂的逻辑、超长的软件生命周期。使用DDD的设计方法是目前看比较合理的选择，维护的成本比较低。
DDD全称是（Domain-Driven Design 领域驱动设计)这是2004年就出来的理论，复杂逻辑的应对之道。
DDD大会在欧洲等地办了一届又一届，CQRS、Event Sourcing等探索层出不穷，
这也是为什么国外比较流行JPA原因。
不过，国内主要是随着这两年随着微服务火爆也有人谈起来DDD了。
但其实DDD也不是银弹，需要大拿能把控全局，国内缺的就是这种大拿，搬砖的太多。
第三点：有些老外在技术选型时，不会考虑除Spring这种知名框架外的其他技术
无他，唯手熟尔。国外一个项目，做了几年十几年都是很正常的。
我以前接触过一个巴基斯坦的电商项目，做了十几年，也跑的好好的，这就是证据。
使用技术也是有惯性的。
第四点：数据体量和种类没有达到
个人感觉，也咨询了国际友人。老外的项目，在数据体量和种类上完全达不到国内的水平。
所以，他们对于性能上的渴求度没有那么高。追求的是稳定，可维护性好。
国内一个双11，如果用hibernate，那只能死掉了。
也说明，老外的需求主要是在业务上，技术层面较少考虑。
7.国人喜欢Mybatis的原因
（1）大厂带节奏
国内做互联网的Java程序很多都是拷贝阿里的，
阿里一开始用例iBatis（日本韩国是怎么回事呢）。
大量的老系统都是基于iBatis/MyBatis的，市场上对MyBatis熟悉的人才更多，
招聘和培训更容易，有的青年程序员以为“MyBatis早已统一全球了”就是一个很好的证明。
（2）简单，学习成本低
小公司需要大量入门级的程序员，像大神甚至一个都请不起，
请问大神们那些牛b框架哪个更快让菜鸟们上手，降低公司学习成本。
注意这个成本会一直跟随公司，想必大神们创业直接前后端分离了，毕竟钱嘛多的是。
（3）对于复杂性需求的灵活性高
国内绝大部分项目都是面向表结构编程的，把java对象仅当成数据容器，
查询和模型变更都设计在一张表上，所谓业务逻辑就是一堆增删改查的sql集合，
当然用mybatis方便。在逻辑不复杂，或者你判断软件生命周期不会超过一年的时候，
直接用表结构编程是最方便快捷的。国内普遍都是分布式，
流量和性能决定了需要经常进行优化，而是用Mybatis对复杂需求的优化很方便。
（4）政治环境
国内好多项目都是应付领导的某些奇葩需求。需要面向领导编程。
一大半时间其实都是在解决领导的需求。国内项目需要大量报表统计（看看帆软卖的这么好就知道了），
需要提供给领导作为决策。看到这里，各位领导不要骂我 ，真的不是黑领导的。
（5）Hibernate学习成本高
虽然，实际上SpringDataJPA是非常简单的，但是，但是，
JPA/Hibernate后期调试跟踪问题很麻烦，改起来也麻烦。
别忘了，牛逼如你的人全公司甚至一个都没。
还有什么缓存什么Criteria什么Lazy，虽然这些你学了也不见得能用上，
但一个框架，你不学还是不行的。而且，JPA对于增删改很方便，复杂查询却是软肋，
有同学会说，JPA也能写SQL语句啊，我想说的是，既然都用orm了，你再写sql，
那不就失去了oop的内涵了吗？不优雅好吧。
8.总的来说：
（1）Mybatis可以进行更细致的SQL优化,查询必要的字段,
但是需要维护SQL和查询结果集的映射。
数据库的移植性较差,针对不同的数据库编写不同的SQL。
Hibernate对数据库提供了较为完整的封装,封装了基本的DAO层操作,
有较好的数据库移植性。但是学习周期长，开发难度大于Mybatis。
两者与Spring的集成都很好，没有区别。
（2）整个状况，和对OOAD的重视有很大关系，我在做DDD技术落地的时候，
用MyBatis非常蹩脚，用JPA/Hibernate会好很多。
JPA/Hibernate比较复杂，团队中要有人Hold住它，否则及其容易踩坑；
另外，真要使用，建议使用它的一个功能子集，不要所有功能都用。
也可以尝试使用更简单EBean ORM。
JPA/Hibernate对分库分表的支持有一下坑。
虽然，使用Shareding-JDBC或MyCat等技术，可以不关心分库分表，
但是，JPA/Hibernate在某些情况下（比如加载子集合的时候）可能会不带分区键。
国外分库分表的少，国内几乎是标配。
