普通程序员和架构师工作任务的一个重要区别就是，普通程序员只需要按照既定的技术路线，老老实实把业务逻辑做出来就行了。而架构师则需要针对业务的类型和需求情况，以及团队的人员能力、技术掌握情况，选择出最适合团队的技术架构，并且贯彻下去。
因此，架构选型的能力，也是判断一个架构师好坏的重要标准之一。
MyBatis和Spring Data Jpa，无疑是目前做各类基于数据库系统最常用的两个持久层框架，那么它们两个又有什么异同呢？对于架构师来讲，又该怎么选择呢？
判断一个技术是否应用在项目中采用，需要判断三个方向，是否满足业务需求限定的约束条件、开发效率如何、性能如何。那么我们就来看看MyBatis和Spring Data Jpa在这三个方向的比较吧。
首先说业务需求，毫无疑问，这两个持久层框架都可以满足，因此无需过多考虑。
其次我们来看一下开发效率方面。
Spring Data Jpa是全自动框架，一般来讲不需要写任何sql，建表的过程也是全自动的，需要写的话，也可以直接写在注解参数里，同时建表的过程也是全自动的，开发者只需要写好对应的类和相关注解而已。而MyBatis是半自动框架，需要自己写sql，也需要自己建表，加上MyBatis-plus后效果差不多。可以说正常来讲Spring Data Jpa开发起来比MyBatis省事一些。
Spring Data Jpa是可以完全与数据库脱钩的，在代码迁移到其它数据库之后，只需要切换对应的Dialect就行了。而MyBatis由于所有SQL都是依赖数据库书写的，所以扩展性，迁移性比较差，则可能需要做更多的工作。
Spring Data Jpa提供了相当多的初级查询自动生成方法例如GreaterThanEqual之类，可以根据方法名自动生成SQL，开发者只需要简单的在接口内写好类似于findByAgeGreaterThanEqual这样的方法名就可以直接使用。非常的简单。
Spring Data Jpa自动生成的sql比较不符合人们的阅读习惯，而MyBatis的Sql则与开发的开发习惯结合较密切，因此在出了问题debug的时候， MyBatis会方便一些。
综上所述，Spring Data Jpa的开发效率会比MyBatis高一些，但是封装的过好，导致学习成本会高一些。
最后我们再来看一下Spring Data Jpa和MyBatis的执行效率问题。
由于Spring Data Jpa的封装更好，所以执行效率要低一些，不过Spring Data Jpa自带缓存优化等，所以这一点区别并不很大。
Spring Data Jpa的insert和update都调用同一个方法save，g data jpa的insert与update都调⽤同⼀个⽅法save，如果带有主键id（如果启⽤了乐观锁，那么还有version字段），那么就是
更新，否则就是新增，所以addOrUpdate是⼀个接⼝，因此要执行两条Sql，先查询，然后再执行插入/更新操作。而MyBatis中提供独立的insert和updateById方法，因此效率要高很多。另外Spring Data Jpa的saveAll()是一条条先查询再插入的，这块效率很低。只能重写saveAll方法，把原来的先查询再插入改成直接插入。
综上所述，Spring Data Jpa在很多地方，执行性能不如MyBatis。
从上面的信息可以看出，Spring Data Jpa适合需要适配不同数据库，对性能要求不高，开发效率要求高的场景，当然在对其进行手动优化之后可以增强其执行性能。
而MyBatis则适合于数据库比较固定，对性能细微差异要求比较高的场景。
联系客服
