MyBatis因为具有封装少，映射多样化，支持存储过程，可以进行SQL优化等特点。使得它取代了Hibernate成为了java互联网中首选的持久框架。
无论MyBatis或Hibernate都可以称为ORM框架，Hibernate的设计理念是完全面向POJO的，而MyBatis不是。
Hibernate基本不再需要编写SQL就可以通过映射关系来操作数据库，是一种全表映射的体现，而MyBatis需要我们提供SQL去运行。程序员不用精通SQL，只要懂得操作POJO就能够操作对应数据库的表。
在管理系统时代，首先是实现业务逻辑，然后才是性能，所以Hibernate在当时是主流。
在移动互联网时代，MyBatis是首选，不屏蔽SQL，程序员可以自己制定SQL规则，能更加精确定义SQL，从而优化性能。更符合移动互联网高并发，大数据，高性能，高响应的要求。
Hiberate和MyBatis的增、删、查、改.对于业务逻辑层来说大同小异，对于映射层而言Hibemate的配置不需要接口和SQL.相反MyBatis是需要的。对于Hibermate而言，不需要编写大量的SQL,就可以完全映射，同时提供了日志、缓存、级联(级联比MyBatis强大)等特性，此外还提供HQL (Hibemate Query Language)对POIO进行操作，使用十分方便，但是它也有致命的缺陷。
由于无须SQL,当多表关联超过3个的时候，通过Hibermate的级联会造成太多性能的丢失，又或者我现在访问一个财 务的表，然后它会关联财产信息表，财产又分为机械、原料等.显然机械和原料的字段是不一样的，这样关联字段只能根据特定的条件 变化而变化，而Hibermate无法支持这样的变化。遇到存储过程，Hibemate只能作罢。更为关键的是性能，在管理系统的时代，对于性能的要求不是那么苛刻，但是在互联网时代性能就是系统的根本，响应过慢就会丧失客户，试想一下谁会去用一个经常需要等待超过10 秒以上的应用呢?
以上的问题MyBatis都可以解决，MyBatis 可以自由书写SQL、支持动态SQL、处理列表、动态生成表名，支持存储过程。这样就可以灵活地定义查询语句，满足各类需求和性能优化的需要，这些在互联网系统中是十分重要的。
但MyBatis也有缺陷。首先，它要编写SQL和映射规则，其工作量稍微大于 Hibemate.其次，它支持的工具也很有限，不能像Hibemate那样有许多的插件可以帮助生成映射代码和关联关系，而即使使用生成工具，往往也需要开发者进一步简化， MyBatis 通过手工编码，工作量相对大些。所以对于性能要求不太苛刻的系统，比如管理系统、ERP 等推荐使用Hibemate;而对于性能要求高、响应快、灵活的系统则推荐使用MyBatis.
！