S08-A03 · ORM 选型：MyBatis vs JPA/Hibernate

适用读者：要在"手写 SQL"与"全自动 ORM"之间做决定的人。
前置：S08-B04。
覆盖旧文：895(69) 490(30) 1743(101) + 空壳 1138 补写（E-S08-015）= 200 点。
上一篇：S08-A02 · 多数据源与动态切换
下一篇：S08-X01 · 八股速查。

1. 一句话结论

MyBatis 把 SQL 交给你，JPA 把 SQL 生成交给你。前者可控、后者省事——选择取决于"SQL 是资产还是负担"。

维度	MyBatis	JPA/Hibernate
SQL 控制	完全手写	自动生成（可 `@Query` 覆盖）
学习曲线	低（会 SQL 就行）	高（脏检查、一级/二级缓存、N+1）
复杂查询	✅ 灵活	⚠️ 需要原生 SQL 兜底
简单 CRUD	❌ 要写	✅ 零 SQL
数据库迁移	改 SQL	改实体 + 方言适配
团队要求	会写 SQL	懂 ORM 语义

2. 选择判据

SQL 是否复杂（多表、窗口函数、优化器提示）？
├── 是 → MyBatis（或 JPA + 原生 SQL）
└── 否 → 是否大量简单 CRUD？
        ├── 是 → JPA / MP（省代码）
        └── 否 → 看团队熟悉度

判断三问：

问	倾向
有 DBA 参与 SQL 评审吗？	有 → MyBatis（SQL 可见）
领域模型复杂、聚合多吗？	复杂 → JPA（对象导航）
团队 SQL 能力强吗？	强 → MyBatis

3. JPA 的四个经典坑

坑	说明
N+1 查询	懒加载在循环里触发 N 次查询
脏检查开销	大事务里对象多时性能差
一级缓存/延迟加载	事务外访问抛异常
自动生成的 SQL 不可控	加索引要靠猜执行计划

这些都是"ORM 抽象泄漏"，与 S08-J03 的 MyBatis 缓存问题同源：抽象层帮你省代码，也帮你藏问题。

4. 混合方案（现实中最多）

场景	用什么
后台管理 CRUD	JPA / MP
报表/复杂查询	MyBatis XML / 原生 SQL
核心交易	手写 SQL + 严格评审

判据："允许同一系统两种 ORM 并存吗？" 允许（常见）→ 按场景选；不允许 → 统一用可控的那个。

5. 迁移与回滚

方向	迁移动作	风险
MyBatis → JPA	实体映射 + Repository 替换	N+1、延迟加载
JPA → MyBatis	补 SQL + 结果映射	工作量集中在 SQL

铁律：DAO 层抽象好接口，迁移才能"只换实现"。

6. 五个误区

误区	真相
"ORM 越自动越好"	自动生成的 SQL 难优化
"MyBatis 过时了"	复杂查询仍是首选
"JPA 不能写 SQL"	`@Query`/原生 SQL 都行
"一个项目只能用一种 ORM"	混合很常见
"选型只看开发效率"	运维与排障成本更大

7. 自检（架构师版）

MyBatis 与 JPA 的本质差异（一句话）？
三问判据分别倾向谁？
JPA 的 N+1 是什么？怎么发现？
混合方案的分界怎么划？
迁移时怎么把风险降到最低？

8. 下一篇

S08-X01 · MyBatis 八股速查

最后一篇是附录：23 道 MyBatis 八股压成"题 → 一句话答案 → 正文位置"。

本篇属于系列《S08 · MyBatis 持久层》。旧文来源：A-895/490/1743（空壳 1138 补写）。