纯无疑问是 JPA 。JPA 是官方的规范，被很多厂商支持，有多种实现。Spring 官方支持，mybaits 需要第三方组件。
抛去规范不谈，JPA 在开发效率上也是完胜。首先是学习成本方面，Spring Data JPA 官方文档随便看看就可以搞起来了，你甚至不需要使用 entityManager 就可以完成业务功能，不用一开始就关注太多 JPA 的概念，学习成本并不高。由于有仓库 Query Methods 的加持，再加上审计功能可以自动管理创建时间等字段，非常的便利，这就是自动化带来的生产力。
相比之下，Mybaits 要写很多 sql ，而且这些 sql 是没有编译检查的，字段什么的写错了，运行时才知道。很多团队选择 Mybatis ，是因为其灵活性，可以写原生 SQL，能方便的完成各种复杂业务，你可以使用数据库特有的功能如窗口函数和递归等，而 JPA 写 jpql 就像隔靴搔痒，很难达到想要的效果，还增加心智负担。JPA 也支持写原生 SQL，但是写了原生 sql 就没有可移植性了。
我个人是不赞成写原生 sql 的，要解决查询问题有很多方法，普通的连表使用 jpql 也就够了，太复杂的查询写了原生 sql 也有性能风险，并不能完善解决问题，对于变态查询的业务实现我有以下建议：减少连表，比如查询某个用户的关联数据，可以先查用户，确定用户再用用户id来查，不连接用户表。使用分布式数据搜索引擎，借助 Elasticsearch 可以完成很多复杂的查询，但是不能把 Elasticsearch 当成数据库用，只能把数据推送给 Elasticsearch 来做查询，会有延迟。
服务器过滤，数据量不大是可以这么做的，注意大列表内存问题。降低查询的精确度，只检索一定范围内的数据，很多电商和搜索引擎都是这么做的，不给用户准确的统计数字。上计算引擎，实时聚合生成要查询的数据。实时性要求不高，不想引入太重的框架也可以定时任务做统计。
暴力扫描数据，但是需要用户等待较长时间，类似我们在 windows 的文件管理器中搜索文件的感觉（windows实际上会对文件创建索引的，但是仍然很慢，关闭 windows search 服务可以节省资源）。
