SpringData JPA 都能写 SQL，为啥还要用 MyBatis？

之前聊过JPA和MyBatis的核心区别，但总觉得没说透。实际开发里，很多人纠结选哪个，不是因为不知道“JPA面向对象、MyBatis面向SQL”，而是踩过具体的小坑后才明白——原来差的是这些细节。今天就从日常写代码的真实场景出发，把两者的差异拆得更细，再贴些实际用到的代码，看完你肯定能更清楚怎么选。

先从最基础的“字段映射”说起吧，这是每个项目都绕不开的。我认为JPA的映射看着方便，但遇到特殊场景就容易卡壳；MyBatis看似麻烦点，却能灵活应对各种奇葩表结构。

比如常见的“数据库字段和Java实体字段不一致”的情况。JPA里得用@Column注解指定列名，要是表字段有下划线（比如user_name），实体字段是驼峰（userName），还得在配置里开驼峰命名自动转换，或者每个字段都加@Column(name = “user_name”)。举个例子：

// JPA实体字段映射（应对下划线字段）@Entity@Table(name="t_user")// 表名和实体名不一致，得指定publicclassUser{@Id@GeneratedValue(strategy=GenerationType.IDENTITY)privateLongid;// 数据库字段是user_name，实体是userName，必须加注解@Column(name="user_name")privateStringuserName;// 数据库字段是create_time，开了驼峰转换才能不用注解privateLocalDateTimecreateTime;// getter/setter...}

要是遇到更特殊的，比如数据库里是varchar类型存的JSON字符串，实体里想直接用JSONObject接收。JPA就得自定义转换器，写个类实现AttributeConverter接口，再在字段上加@Convert注解，步骤不少。

但MyBatis处理这些就简单直接。字段映射可以在XML里用resultMap明确指定，哪怕字段名完全不一样，也能精准匹配，不用改实体类注解：

<!-- MyBatis XML 字段映射 --><resultMapid="UserResultMap"type="com.example.entity.User"><idcolumn="id"property="id"/><!-- 数据库user_name对应实体userName，直接指定 --><resultcolumn="user_name"property="userName"/><!-- 数据库create_time对应实体createTime，不用额外配置 --><resultcolumn="create_time"property="createTime"/><!-- JSON字符串转JSONObject，直接用TypeHandler --><resultcolumn="ext_info"property="extInfo"typeHandler="com.example.handler.JsonTypeHandler"/></resultMap><!-- 查询时指定resultMap即可 --><selectid="getUserById"resultMap="UserResultMap">SELECT id, user_name, create_time, ext_info FROM t_user WHERE id = #{id}</select>

在我看来，这种细节上的灵活度，就是很多人宁愿多写点SQL，也选MyBatis的原因——遇到奇葩表结构，不用跟框架“掰扯”，直接按自己的想法来就行。

再说说动态SQL，这也是日常开发高频场景。比如做一个列表查询，前端可能传用户名、状态、时间范围，也可能都不传，需要动态拼接WHERE条件。JPA和MyBatis都能做，但写起来的体验天差地别。

JPA里常用的是Specification或者JpaRepository的方法名派生。方法名派生只能应对简单条件，比如按用户名模糊查询+状态匹配，写个findByUserNameLikeAndStatus就行。但条件一多，方法名会变得巨长，比如findByUserNameLikeAndStatusAndCreateTimeBetweenAndDeptId，看着就头疼，后期改条件也容易写错。

用Specification会灵活点，但代码写起来很繁琐，尤其是多表关联的时候：

// JPA 用Specification做动态查询（用户名模糊+状态+时间范围）publicPage<User>queryUser(StringuserName,Integerstatus,LocalDateTimestartTime,LocalDateTimeendTime,Pageablepageable){returnuserRepository.findAll((root,query,cb)->{List<Predicate>predicates=newArrayList<>();// 用户名模糊查询if(StringUtils.isNotBlank(userName)){predicates.add(cb.like(root.get("userName"),"%"+userName+"%"));}// 状态匹配if(status!=null){predicates.add(cb.equal(root.get("status"),status));}// 时间范围if(startTime!=null&&endTime!=null){predicates.add(cb.between(root.get("createTime"),startTime,endTime));}// 拼接条件returncb.and(predicates.toArray(newPredicate[0]));},pageable);}

这段代码能跑，但读起来费劲，尤其是新人接手，得琢磨半天每个Predicate对应什么条件。而且多表关联时，root.join()的写法很容易出错，调试起来也麻烦。

再看MyBatis的动态SQL，直接在XML里用if、choose、where标签写，逻辑清晰，还能加注释，哪怕条件再多，也能看得明明白白：

<!-- MyBatis 动态SQL（和上面JPA同样的查询条件） --><selectid="queryUser"resultMap="UserResultMap">SELECT id, user_name, status, create_time FROM t_user<where><!-- 用户名模糊查询，非空才拼接 --><iftest="userName != null and userName !=''">AND user_name LIKE CONCAT('%', #{userName}, '%')</if><!-- 状态匹配，非空才拼接 --><iftest="status != null">AND status = #{status}</if><!-- 时间范围，两个都非空才拼接 --><iftest="startTime != null and endTime != null">AND create_time BETWEEN #{startTime} AND #{endTime}</if></where>ORDER BY create_time DESC LIMIT #{pageNum}, #{pageSize}</select>

我们的经验是，动态条件超过3个，用MyBatis写起来效率更高，后期维护也更省心。哪怕是新人，只要懂SQL，就能看懂这段XML里的逻辑，改条件的时候直接加个if标签就行，不用记JPA的各种API。

再聊个深入点的——多表关联查询。JPA的优势是能通过@OneToMany、@ManyToOne这些注解定义实体间的关联关系，查询的时候用fetch指定懒加载或急加载，就能自动关联查询出关联对象。比如查询用户的时候顺带查出用户的订单列表：

// JPA 多表关联（用户-订单 一对多）@EntitypublicclassUser{@IdprivateLongid;privateStringuserName;// 关联订单表，急加载@OneToMany(fetch=FetchType.EAGER)@JoinColumn(name="user_id")// 订单表的user_id关联用户表idprivateList<Order>orderList;// getter/setter...}// 查询用户时自动带出订单列表Useruser=userRepository.findById(1L).orElse(null);List<Order>orderList=user.getOrderList();// 直接获取，不用额外查询

这种写法看着方便，但坑也藏在这里。要是关联的表多，比如用户关联订单、订单关联商品、商品关联分类，JPA会生成一堆JOIN语句，甚至出现N+1查询问题（查1个用户带出N个订单，会执行1次查用户+N次查订单的SQL），性能直接拉胯。虽然能通过fetch join优化，但需要手动写JPQL，而且优化的度很难把握。

MyBatis处理多表关联，是手动写JOIN SQL，虽然要自己写关联条件，但能精准控制查询的字段和关联的表，避免冗余查询。比如同样查询用户和订单，只查需要的字段：

<!-- MyBatis 多表关联查询（用户+订单） --><resultMapid="UserWithOrderResultMap"type="com.example.entity.User"><idcolumn="user_id"property="id"/><resultcolumn="user_name"property="userName"/><!-- 关联订单列表 --><collectionproperty="orderList"ofType="com.example.entity.Order"><idcolumn="order_id"property="id"/><resultcolumn="order_no"property="orderNo"/><resultcolumn="amount"property="amount"/></collection></resultMap><selectid="getUserWithOrder"resultMap="UserWithOrderResultMap">SELECT u.id as user_id, u.user_name, o.id as order_id, o.order_no, o.amount FROM t_user u LEFT JOIN t_order o ON u.id = o.user_id WHERE u.id = #{id}</select>

这段SQL只查了需要的字段，没有多余的关联，执行效率更高。而且如果不需要订单列表，直接查用户表就行；需要的时候再写关联查询，灵活度拉满。要是遇到复杂的多表关联，还能拆分成多个简单查询，手动控制事务，比JPA的“黑盒优化”更让人放心。

最后再补充个细节——SQL的可调试性。JPA自动生成的SQL，有时候会很“奇葩”，比如字段名用奇怪的别名，排序逻辑不清晰。要是查询结果不对，想调试SQL都难，只能开启SQL日志，复制出来格式化后才能排查问题。

MyBatis就不一样了，写的SQL就是最终执行的SQL（除了动态拼接的部分），要是查询有问题，直接把XML里的SQL复制到数据库客户端，替换掉#{参数}，执行一下就能定位问题。比如遇到查询结果为空，先在客户端跑SQL，看是条件错了还是字段错了，几分钟就能搞定，不用跟JPA的日志“较劲”。

总结下吧，我不是说JPA不好，它在标准CRUD、快速开发场景下确实香，适合领域模型清晰、SQL复杂度低的项目。但在细节把控上，比如字段映射、动态SQL、多表关联、性能优化，MyBatis的优势太明显了。

在我看来，选框架不是看哪个“高级”，而是看哪个更适配项目。如果是初创项目，追求快速上线，团队SQL能力一般，选JPA没问题；如果是中大型项目，有大量复杂查询，对性能要求高，或者需要DBA介入优化SQL，MyBatis绝对是更稳妥的选择。

现在很多项目都是“JPA+MyBatis”混着用，用JPA做简单的增删改查，用MyBatis处理复杂查询和报表。这种组合既能享受JPA的开发效率，又能拥有MyBatis的灵活度，算是兼顾效率和性能的最优解了。