寇亚君
个人认为mybatis可以做到代码与SQL解耦，单表查询用jpa倒是没什么，要是写统计或者复杂查询之类的jpa就不太友好了，需要代码逻辑跟SQL耦合起来，代码可读性和可维护性不好。最近基于jdbcTemplate做了一套自定义动态查询，也将sql放在了配置文件中，也是为了降耦和提高代码可读性，还可以根据业务场景定制很多功能。
Java修炼者
头条上问这种问题也是醉了。。看到了顺便答一波，瞎扯的人太多。
国内的设计思路是table driven的，简单来说，用数据表定逻辑，用模型做实现，实际这是和面向对象相反的思路。mybatis所谓的灵活性在大多数工程师手里就是不用考虑模型如何设计，“反正我用原生sql都能解决”，模型设计的烂的一逼，全靠sql去修修补补。而jpa是完全object driven的思路，前期设计的缺陷会很制约后续开发，并且不同的数据库可做不同的实现（实际是哪怕是redis也是一样的）。回答几个常见sb问题。
1.jpa表连接行为不确定，难以控制。
你确定你用过spring data jpa？不知道有EntityGraph ？傻瓜到这种程度了还能咋的。
2.jpa子查询不好实现。
我估计你都没用过吧？spring data jpa的子查询既可以单独定义视图，也可以做subquery，甚至直接用jpql。
3.jpa不好优化。
我真不信99%得优化能超过spring data jpa的优化，尤其是一般般的程序员能别把优化放嘴上么，连mysql的锁都搞不清楚，表设计的跟坨屎一样还天天原生sql，觉得自己很牛逼么？jpa是可以把表属性反应到对象的，天然就有运行时优化的底子在，ORM能发展的空间太大了，稍微有点技术认知的都知道ORM会优势越来越大。稍微有些经历的程序员都知道现在是先说好维护才说其他的，能解决性能的方法太多了好么。
最后，难道不知道现在提倡ORM+CQRS么？请问，有啥复杂的解决不了，都不需要native sql介入好么。
NovRain61
spring data jpa在复杂查询上可以使用query+new 构造方法或者视图的方式去查询，至于说效率，我想应该是在POJO中使用@OneToMany或者@ManyToMany的注解导致的，一般情况下尽量使用@ManyToOne就可以了
草莓爱旅行
用mybatis就是为了照顾大多数[机智][机智][机智]
完了，我会被喷死[捂脸][捂脸][捂脸]
