一文详解为什么 JPA 会慢？JPA 底层执行流程深度解析
很多开发者在使用 JPA（Hibernate）一段时间后，都会产生类似的疑问：
❓ 同样的查询，JPA 比 MyBatis 慢
❓ 明明只查一次，却发了很多 SQL
❓ 一个简单的 save，数据库却执行了 update
结论先行一句话：
👉JPA 慢，不是慢在 JDBC，而是慢在“ORM 自动化与对象管理成本”
下面我们从底层执行流程开始，一步步拆开来看。
一、JPA 整体执行流程（总览）
先看一张文字版执行流程图，后面每一步都会详细解释。
Repository 方法调用 ↓ Spring Data JPA 代理 ↓ 解析方法名 / JPQL ↓ Hibernate Session（EntityManager） ↓ 一级缓存（Persistence Context） ↓ 脏检查 / 实体状态管理 ↓ SQL 生成器（HQL → SQL） ↓ JDBC PreparedStatement ↓ 数据库执行 ↓ ResultSet → 实体对象 ↓ 放入一级缓存注意：
JPA ≠ Hibernate
Hibernate 才是性能差异的核心来源
二、为什么 JPA 会慢？核心原因拆解
原因 1：多了一整套 ORM 对象管理机制
MyBatis：
SQL → JDBC → ResultSet → DTOJPA：
SQL → Entity → 持久化上下文 → 状态管理 → 脏检查👉 JPA 不只是“查数据”，而是：
管理实体生命周期
维护对象状态
自动决定是否发 SQL
📌这些“聪明”的事情，全都是性能成本
原因 2：一级缓存（Persistence Context）
JPA 内部有一个一级缓存（默认开启）：
User u1 = em.find(User.class, 1L); User u2 = em.find(User.class, 1L);📌 实际只会发一次 SQL
但代价是：
所有查询结果都要放进内存
实体需要被 Hash / 比较 / 管理
大批量查询容易 OOM
👉缓存是双刃剑
原因 3：脏检查（Dirty Checking）
这是 JPA 性能“杀手级”的地方。
什么是脏检查？
@Transactional public void updateUser() { User u = userRepo.findById(1L).get(); u.setName("Tom"); }你没有写update，但 JPA 会：
保存查询时的快照
事务提交前比较属性
判断是否变化
自动生成
update SQL
📌每一个实体，都会做字段级对比
当数据量大时：
CPU 消耗明显
GC 压力大
性能不可预测
原因 4：N + 1 查询问题（最常见）
场景
List<Order> orders = orderRepo.findAll(); for (Order o : orders) { o.getUser().getName(); }如果Order -> User是LAZY：
1 次：select * from order N 次：select * from user where id=?👉这不是 JPA 的 bug，是 ORM 的设计代价
📌 MyBatis 不会出现，除非你自己写错 SQL。
原因 5：SQL 不可控 & 不透明
JPA 的 SQL 来源可能是：
方法名解析
JPQL
Criteria API
自动 flush 触发
开发时你写的是：
save(entity)运行时你看到的是：
select ... update ... select ...👉调优难度远高于 MyBatis
原因 6：自动 flush 时机不可预测
以下情况都会触发 flush：
执行查询前
事务提交前
手动调用
flush()
save(a); find(b); // 可能会触发 flush📌你以为是查询，结果先 update 了
三、JPA vs MyBatis 执行流程对比
MyBatis（极简）
Mapper 方法 ↓ XML / 注解 SQL ↓ JDBC ↓ 数据库JPA（完整版）
Repository ↓ Spring Data 代理 ↓ Hibernate Session ↓ 一级缓存 ↓ 实体状态判断 ↓ 脏检查 ↓ SQL 生成 ↓ JDBC ↓ 数据库👉慢的不是 SQL，而是 SQL 之前的“智能处理”
四、什么时候 JPA 会“特别慢”？
⚠️ 高危场景：
大批量查询（>1w 条）
循环中访问懒加载属性
频繁 save / update
多表关联 + 默认 fetch
不理解 flush / clear
五、JPA 其实并不“天生慢”
合理使用后，JPA 可以很快
优化手段：
@BatchSizejoin fetchDTO 投影（避免实体）
clear()控制缓存禁用不必要的级联
大数据量用 MyBatis
📌JPA 的正确定位：业务开发工具，不是 SQL 引擎
六、最佳实践（强烈推荐）
JPA + MyBatis 混合使用
JPA：
单表 CRUD
简单业务逻辑
MyBatis：
复杂 SQL
报表
大数据量
这是真实一线项目最常见的选择。
七、总结
JPA 慢的根本原因，是为了对象一致性和开发效率，引入了缓存、脏检查、实体状态管理等机制，而不是 JDBC 慢。
