当前位置：首页 > news >正文

SpringData JPA也能写sql，为什么还要用mybatis?

news 2026/6/10 2:28:06

因为在中大型系统里，可控比省事重要的多。MyBatis 的核心价值不是能写SQL，而是它在：开发效率、SQL可控、性能底线，给了一个最稳的平衡点。

我们作为程序员，日常在做技术架构设计时，也是一个寻找最佳平衡的过程，很少有绝对完美的解决方案的，选择最佳平衡最合适当前实际情况的就可以了。

网络上也有部分人拿Spring Data JPA 也能写原生 SQL来反驳：那 JPA 不就同时拥有便利 + SQL 灵活了吗？

真正负责过中大型系统就会知道：能写SQL ≠ 适合把SQL当成主战场。尤其当你的系统进入“数据量大、查询复杂、DBA开始介入治理”的阶段。

数据库是瓶颈：SQL 必须“可解释、可控、可审”

在日常的业务开发中，如果你做的多了，经历的项目也多了，会发现，好多系统的瓶颈就出在数据库。我相信经验丰富的人，不会反驳这一点。当生产环境里的业务系统接口的响应变慢了，定位下来后，好多都是跟SQL相关的，也经常会如下去处理：

SQL 长什么样？走了哪个索引？
扫了多少行？有没有回表？
join 顺序对不对？分页对不对？
where 条件有没有不标准的写法导致索引失效？
锁范围有多大？会不会把别人卡死？

我们要写好SQL尚且是一个难题，那直接让ORM去生成SQL，则更加不靠谱。

MyBatis的优势之一：所见即所得。
你写下的 SQL 就是最终执行的 SQL，DBA 看得懂，研发也能 explain、能优化、能对比。

而 JPA（Hibernate）的设计目标恰好相反：
它希望你从“对象关系”出发，把 SQL 的细节藏起来。

这在简单 CRUD 上确实省事，但在高并发/大数据量场景下，你会遇到两个典型坑：

不可预期的 SQL：关联关系、懒加载、级联、flush 时机，一变就可能多出几条 SQL
排查链路长：慢了之后你不是直接改 SQL，而是在改实体映射策略、Fetch、关联关系，牵一发而动全身

因此：

MyBatis更像是“把数据库当核心资产来治理”的，SQL是它的一等公民

JPA支持原生SQL，但复杂结果映射支持的不是很友好

JPA 的确可以@Query(nativeQuery = true)写 SQL。但有一个问题，复杂SQL的结果如何很好的映射回到Java的对象里？

举一个例子：查用户列表 + 部门名 + 最近一年订单总额。

JPA（原生 SQL 的常见落地形态）

@Query(value=""" SELECT u.id, u.name, d.dept_name, SUM(o.amount) total_amount FROM t_user u JOIN t_dept d ON d.id = u.dept_id LEFT JOIN t_order o ON o.user_id = u.id AND o.created_at >= :since GROUP BY u.id, u.name, d.dept_name """,nativeQuery=true)List<Object[]>userReport(@Param("since")LocalDateTimesince);

接下来你要做的是：

处理Object[]，手动转 DTO；
用 Projection（字段名对齐、类型对齐等）；
用构造函数表达式。

一旦字段多、join 多、统计多，映射逻辑会越来越多。

MyBatis（结果集映射是强项）

MyBatis 的ResultMap/resultType天然就是为这种场景准备的：
你只需要明确“列 -> 字段”的映射关系。

<resultMapid="UserReportMap"type="com.example.dto.UserReportDTO"><idproperty="userId"column="id"/><resultproperty="userName"column="name"/><resultproperty="deptName"column="dept_name"/><resultproperty="totalAmount"column="total_amount"/></resultMap><selectid="userReport"resultMap="UserReportMap">SELECT u.id, u.name, d.dept_name, SUM(o.amount) AS total_amount FROM t_user u JOIN t_dept d ON d.id = u.dept_id LEFT JOIN t_order o ON o.user_id = u.id AND o.created_at >= #{since} GROUP BY u.id, u.name, d.dept_name</select>

这里也可能有人会反驳说，JPA不是有@SqlResultSetMapping和接口投影技术来解决这个问题吗? 算数了，我为了一个映射，还得引入那么多东西，复杂性和维护性都提高了。

JPA写复杂SQL不是不能写，是写完之后落地成本高，MyBatis是把复杂查询 + 映射当主场来设计的。

动态 SQL：这是MyBatis的杀手锏，也是JPA的痛点

我们再来一个需求：用户列表搜索接口，10 个查询条件，全是可选。

name 模糊
status
phone
createdAt 范围
ids in (…)
deptId/ 渠道来源 / 注册方式……
还要分页、排序

在JPA可以怎么做?

拼字符串：可读性差、容易出错，也容易留下安全隐患
Specification/Criteria API：能写，但代码很绕，维护成本高（很多项目写着写着就开始受不了”）
引入 QueryDSL：能解决一部分，但又引入一套新体系，学习/维护成本并不低

MyBatis 的写法（直观、可维护）

<selectid="searchUsers"resultType="User">SELECT id, name, phone, status, created_at FROM t_user<where><iftest="name != null and name != ''">AND name LIKE CONCAT('%', #{name}, '%')</if><iftest="status != null">AND status = #{status}</if><iftest="ids != null and ids.size > 0">AND id IN<foreachcollection="ids"item="id"open="("separator=","close=")">#{id}</foreach></if></where>ORDER BY id DESC LIMIT #{offset}, #{pageSize}</select>