从 MyBatis 到 JPA：一个 CRUD 程序员的认知重建

痛点一：第一天进新公司，代码里全是 @Entity、@OneToMany、@ManyToOne、EntityManager、JPQL…却找不到一行 SQL，也找不到 XML Mapper。说起来，

SQL 就是安全感。接口慢，打开 XML 看 SQL。数据不对，打开 XML 看 SQL。排查问题，打开 XML 看 SQL。一切尽在掌控，

但调 departmentRepository.findById 时日志里蹦出七八条不明来源的 SQL，你会慌。

别焦虑：这篇文章不是 JPA 教程，也不是“JPA 比 MyBatis 好”的布道文。而是记录一个习惯了 SQL‑first 思维的开发者，在被迫使用 ORM‑first 框架后经历的四次认知重建。如果你也面临一样的切换，这些内容可以帮你少走一周的迷茫。

环境信息

项目结构

jpa-mindset-shift/
├── pom.xml
└── src/
├── main/java/com/coderplus/jpademo/
│ ├── Application.java
│ ├── entity/
│ │ ├── Employee.java # 员工实体
│ │ ├── Department.java # 部门实体
│ │ └── Project.java # 项目实体
│ ├── repository/
│ │ ├── EmployeeRepository.java
│ │ └── DepartmentRepository.java
│ └── service/
│ └── EmployeeService.java # 四个要点的演示方法
└── test/java/com/coderplus/jpademo/
├── Point1_DirtyCheckingTest.java # 要点1：我没调 save，数据怎么变了？├── Point2_NPlusOneTest.java # 要点2：查 条数据，SQL 刷了 行？├── Point3_DetachedEntityTest.java # 要点3：数据一会儿存进去了一会儿又没了？不过，└── Point4_CascadeTest.java # 要点4：删一个员工。部门怎么也没了，怎么说呢，

至于认知重建之前。先理解 MyBatis 和 JPA 在“争”什么

痛点二：把 MyBatis 的思维模型硬套到 JPA，结果每一次框架自动生成的 SQL 都让你觉得“车失控”。

MyBatis 的思维模型：
你 → 写 SQL → 数据库执行 → 结果映射到对象
JPA 的思维模型：
你 → 操作对象 → 框架生成 SQL → 数据库执行 → 对象状态自动同步

主要区别：MyBatis 是 SQL‑centric，JPA 是 Object‑centric。

要点1 ：我没调 save，数据怎么自己变了？

场景描述 & 痛点三：

@Transactional
public void updateEmployeeSalary {
Employee emp = employeeRepository.findById.orElseThrow;emp.setSalary;emp.setUpdateTime);// 故意不调 save
}

方法执行完后去库里查——salary 和 update_time 已经被更新。

SQL 日志揭示真相 & 痛点四：

Hibernate: select e1_0.id。e1_0.department_id,e1_0.name,e1_0.salary,e1_0.update_time from t_employee e1_0 where e1_0.id=?怎么说呢，Hibernate: update t_employee set department_id=?,name=，,salary=?,update_time=?where id=，

持久化上下文 + 脏检查& 痛点五：

Persistence Context相当于“一层对象快照缓存”。话说回来，当事务提交或显式 flush 时Hibernate 会把托管态实体当前值与快照对比。有差异就自动生成 UPDATE。

• flush 触发时机：
• 事务提交前
• 显式调用 entityManager.flush/repository.flush
• 执行 JPQL/HQL 查询前

JPA 实体四种状态 & 痛点六：

Dirt​y Checking 只对 Managed 实体生效，这解释了为什么同一个对象在事务内改了会更新，而事务外改了却没有反应。说起来，

MyBatis 思维 → JPA 思维的转变 & 痛点七：

要点2 ：查 一条员工信息，SQL 日志刷了 N 条！

场景描述 & 痛点八：

& @GetMapping public Employee getEmployee { return employeeRepository . findById . orElseThrow;}

Hibernate : select …from t_employee where id =?Hibernate : select …from t_department where id =?Hibernate : select …from t_project where owner_id =?，

痛点九：查询一次却产生 N+ 条 SELECT； 按理说，生产环境直接把 DB 打穿。

实体关系图 & 痛点十 ：懒加载被意外触发

java @Entity public class Employee { @Id @GeneratedValue private Long id;private String name;private BigDecimal salary;

@ManyToOne // 默认 EAGER，需要显式设为 LAZY
private Department department;@OneToMany // 默认 LAZY
private List projects;

}

`findById` 本身只查出 Employee；怎么说呢，但 Spring MVC 序列化成 JSON 时会调用 `getDepartment`、`getProjects` 等懒属性。从而触发额外 SELECT。这个“明明不是我写的 SQL。却在跑”的感觉，是 JPA 初学者最常踩的坑。

三种解法 & 痛 点十一：

• 方案 A：JOIN FETCH —— 手写 JPQL，一次查询搞定

& @Query ( "SELECT e FROM Employee e "
+ "JOIN FETCH e.department "
+ "JOIN FETCH e.projects "
+ "WHERE e.id = :id" )
Optional findByIdWithDetails Long id);

& // 在 Repository 方法上直接声明要加载的关联属性
@EntityGraph
Optional findWithGraphById;

& @BatchSize
@OneToMany
private List projects;

隐藏雷区这方面，MultipleBagFetchException java @Query 执行时抛出 `MultipleBagFetchException`——同一个实体不能急加载两个未加 `@OrderColumn` 的 `List`。解决办法这方面，

• 把其中一个 `List` 改为 `Set`；或
• 仅对一个集合使用 `JOIN FETCH`，另一个靠 `@BatchSize` 或单独查询。

何时选哪种方案？less 查询简单、关联少 → @EntityGraph 查询复杂、多条件排序 → JOIN FETCH JPQL 关联很多、不经常一起查 → @BatchSize JSON 序列化 → 别直接返回 Entity，用 DTO 或 JOIN FETCH 替代 多个 OneToMany 同时 FETCH→ 将其中一个改为 Set 或使用 BatchSize

Spring Boot 默认值提醒 & 痛 点十二：

`spring.jpa.open-in-view=false` 在新版默认关闭。这代表着 Controller 返回 Entity 时如果懒属性被序列化，会抛 `LazyInitializationException` 而不是悄悄跑 N 条 SELECT。话说回来，它让问题**立刻暴露**，比静默拖垮性能更安全。但如果升级后突然看到该异常，请改为 DTO 或显式 fetch。而不是把 open‑in‑view 再开回去。

要点3 ：数据一会儿存进去了一会儿又没了！

场景描述 & 痛 点十三：

java @PutMapping public Employee updateSalary(@PathVariable Long id,@RequestParam BigDecimal salary) { Employee emp = employeeRepository.findById.orElseThrow;emp.setSalary;employeeRepository.save;// 明明调了 save return emp;}

有时更新成功，有时却没有任何变化——同一段代码表现不一致。

根因的观点是，Detached Entity 与 save 实际行为

• 方法缺少 @Transactional —— findById 在隐式事务中执行完毕后即提交。使返回的 emp 成为 Detached 状态。
• save 对 Detached 实体内部实际调用的是 merge；如果合并过程中发现属性值与 DB 相同或脏检查判断为未变，则不会产生 UPDATE。
• merge 会返回一个新的 Managed 实体。但我们仍然返回原来的 Detached 对象，于是看起来好像 “保存失败”。

正确姿势 & 痛 点十四：

@Transactional // 整个方法保持同一个事务边界
public Employee updateSalary {
Employee emp = employeeRepository.findById.orElseThrow;// Managed 全程受管
emp.setSalary;// 不必再调用 save
return emp;话说回来，// 返回的是 Managed 实体。事务提交时自动 flush 更新 DB
}

┌─────────────────────────────────────┐
│ Controller │
│ • 接收请求 │
│ • 调 Service │
│ • 不直接操作/返回 Entity │
└─────────────────────────────────────┘
▼ Transactional Boundary
┌─────────────────────────────────────┐
│ Service │
│ • 标注 @Transactional │
│ • 在这里修改 Entity 属性 │
│ • 方法结束即提交事务 │
└─────────────────────────────────────┘
▼ Persistence Context
┌─────────────────────────────────────┐
│ Hibernate Session │
│ Managed 实体 ↔ 数据库 自动同步 │
└─────────────────────────────────────┘
※ 方法外返回的对象已成为 Detached，不再受管理。按理说，

要点4 ：删了一个员工。部门数据也跟着消失，

java @Entity public class Employee { // ... @OneToMany(mappedBy = "owner"。cascade = CascadeType.ALL,orphanRemoval = true) private List projects = new ArrayList<>;}

java @Transactional public void removeProjectFromEmployee { Employee emp = employeeRepository.findById.orElseThrow;emp.getProjects.removeIf.equals);employeeRepository.save;话说回来，}

执行后 项目记录被物理删除导致其他业务也受影响。

说到根因分析，orphanRemoval + CascadeType.ALL

• orphanRemoval=true ⇒ 当子实体从父集合中移除且不再被其他父引用时会 DELETE 它。
• CascadeType.ALL 包含 REMOVE ⇒ 删除操作会级联传播到子实体。

推荐做法 & 痛 点十六：

• cascade 应该只声明真正需要级联的操作。如 {PERSIST,MERGE}；不要盲目使用 ALL。

• java // ✅ 正确，仅级联保存/合并，不级联删除 @OneToMany(mappedBy = "owner"。cascade = {CascadeType.PERSIST,CascadeType.MERGE}) private List projects;

  // ✅ 手动删除 @Modifying @Query void deleteProject Long projectId,@Param Long ownerId);

  级联操作速查表 & 痛 点十七：

  \DETACH 父实​​体脱管时子也脱管 <\/ t d> 极少需求 <\/ t d> ⚠️ 不推荐 <\/ t d> <\/ tr> \ALL 以上全部 <\/ t d> 看似省事，却容易埋雷 <\/ t d> ❌ 基本不要用 <\/ t d> <\/ tr \/> <\/ tbody \/> <\/ table \/>

  Cascade 类型	Description	#适用场景	#建议使用度
  PERSIST	保存父实体时自动保存子实体	子实体生命周期完全由父管理	✅ 常用 <\/tr>
  MEREGE	合并父实体时自动合并子实体	同上	✅ 常用 <\/tr>
  \REMOVE	删除父实体时自动删除子实体	仅当子实体不会被其他父引用	⚠️ 谨慎 <\/tr>
  \REFRESH	刷新父实体时同步子实体	极少使用 <\/t d> ✅ 可选<\/t d> <\/ tr>

  ---

  --- End of content---