MyBatis 和 Hibernate（JPA）有什么区别？各自适合什么场景？

简化版

两者都是持久层框架，但定位不同：Hibernate（JPA）是全自动 ORM——把对象和数据库表完全映射，你操作对象、它自动生成 SQL，几乎不用写 SQL，开发快、跨数据库好，但SQL 不可控（复杂查询、优化困难）、学习曲线陡；MyBatis 是半自动的 SQL 映射框架——SQL 你自己写（写在 XML 或注解里），MyBatis 负责把参数绑定进 SQL、把结果映射成对象，SQL 完全可控、灵活、易优化，但要手写 SQL、跨数据库要改 SQL。一句话：Hibernate 帮你写 SQL（全自动、屏蔽 SQL）、MyBatis 让你写 SQL（半自动、掌控 SQL）。国内互联网偏爱 MyBatis（SQL 可控、便于优化）。

详细版

核心对比：

维度	Hibernate（JPA）	MyBatis
定位	全自动 ORM（对象-关系映射）	半自动 SQL 映射框架
SQL	框架自动生成（HQL/Criteria）	开发者手写（XML/注解）
SQL 可控性	弱（自动生成，难精确优化）	强（自己写，可精确优化）
开发效率	高（简单 CRUD 几乎零 SQL）	中（要写 SQL 和映射）
学习曲线	陡（缓存、懒加载、状态管理复杂）	平缓（就是 SQL + 映射）
跨数据库	好（改方言即可）	弱（换库要改 SQL）
复杂查询/优化	困难（生成的 SQL 不透明）	容易（SQL 在手，随意优化）
缓存	强大（一级、二级、查询缓存）	有（一级、二级，但二级少用）

同一个查询的写法对比：

// Hibernate/JPA：面向对象，不写 SQL
@Entity
public class User { @Id Long id; String name; }
// Spring Data JPA：连实现都不用写，方法名即查询
List<User> findByNameAndAgeGreaterThan(String name, int age);  // 自动生成 SQL

// MyBatis：自己写 SQL
@Select("SELECT * FROM user WHERE name = #{name} AND age > #{age}")
List<User> selectByNameAndAge(String name, int age);   // SQL 一目了然、可优化

⚠️ 别把「MyBatis 半自动」理解成「MyBatis 落后」——恰恰相反，「SQL 可控」在国内互联网大厂是优势：高并发场景要精细优化 SQL（索引、执行计划、避免全表扫描），Hibernate 自动生成的 SQL 难以精确控制和优化，而 MyBatis 的 SQL 完全在你手里，哪里慢改哪里。这是国内互联网偏爱 MyBatis 的核心原因。

完整版教学

一、两种持久层哲学：屏蔽 SQL vs 掌控 SQL

两个框架代表了持久层的两种设计哲学：

Hibernate 哲学：让开发者「忘记 SQL」，只面向对象编程
  你操作 User 对象（save/update/delete），框架自动翻译成 SQL
  理想：数据库是实现细节，开发者不用关心 SQL

MyBatis 哲学：让开发者「掌控 SQL」，框架只做映射
  你写 SQL，框架帮你绑参数、映射结果
  理想：SQL 是核心资产，开发者应该完全掌控它

这两种哲学没有绝对的对错，是**「开发效率」和「SQL 可控性」的权衡**。Hibernate 用「屏蔽 SQL」换开发效率（简单 CRUD 飞快），代价是复杂场景 SQL 难控；MyBatis 用「手写 SQL」换可控性（优化随心），代价是要多写 SQL。理解这两种哲学，就理解了后面所有具体差异——它们都是这两种取向的延伸。

二、全自动 vs 半自动：SQL 谁来写

最核心的区别是「SQL 由谁产生」：

Hibernate（全自动）：
  session.save(user)  →  框架自动生成 INSERT INTO user(...) VALUES(...)
  你几乎不写 SQL，用 HQL（面向对象的查询语言）或方法名查询

MyBatis（半自动）：
  <insert>INSERT INTO user(name, age) VALUES(#{name}, #{age})</insert>
  SQL 是你写的，MyBatis 负责：把 #{name} 换成参数、把结果集映射成对象

「半自动」的含义：MyBatis 自动化了「参数绑定」和「结果映射」这两件繁琐的事（这是纯 JDBC 最麻烦的部分），但把「写 SQL」这件事留给你。所以它介于「纯 JDBC（全手动）」和「Hibernate（全自动）」之间——比 JDBC 省事（不用手动 setParameter、getResultSet），比 Hibernate 可控（SQL 自己写）。这个定位让它「灵活 + 不繁琐」，很符合需要精细控制 SQL 的场景。

三、SQL 可控性：为什么大厂偏爱 MyBatis

「SQL 可控」听起来是「要多干活」，但在高并发场景反而是核心优势：

高并发下的现实需求：
  - 要精确控制 SQL 走哪个索引（FORCE INDEX）
  - 要避免全表扫描、避免回表、控制 JOIN 顺序
  - 慢查询要能精确定位到某条 SQL 并优化它
  - 要写复杂的统计/报表 SQL（多表 JOIN、子查询、窗口函数）

Hibernate：SQL 是框架自动生成的
  → 你看不到、控制不了它生成什么 SQL
  → 复杂查询生成的 SQL 可能很低效，难以优化
  → N+1 问题、笛卡尔积等隐患不易察觉

MyBatis：SQL 完全是你写的
  → 慢查询一眼定位、随时优化、精确控制执行计划

这就是国内互联网大厂普遍用 MyBatis 的根本原因——它们的业务是高并发、大数据量，SQL 性能是生命线，必须能精确控制和优化每一条 SQL。Hibernate 的「屏蔽 SQL」在这种场景下反而成了障碍（你想优化却够不着底层 SQL）。而 Hibernate 更适合「业务简单、CRUD 为主、追求开发速度、对性能不极致」的场景（如内部管理系统、快速原型）。

四、开发效率与学习曲线的取舍

从开发效率和上手难度看，两者也是此消彼长：

Hibernate：
  简单 CRUD 开发快（Spring Data JPA 甚至方法名就是查询，零 SQL）
  但学习曲线陡——要理解：
    - 对象的状态（瞬时/持久/游离/删除）和状态转换
    - 一级/二级缓存、脏检查、flush 时机
    - 懒加载、级联、fetch 策略、N+1
  这些概念多且容易踩坑（如 LazyInitializationException）

MyBatis：
  要写 SQL 和 ResultMap（简单 CRUD 反而比 JPA 多写点）
  但概念简单——就是「写 SQL + 参数绑定 + 结果映射」，几乎没有隐藏的魔法
  上手快、行为可预测

一个权衡：Hibernate「简单场景省事、复杂场景费劲」，MyBatis「简单场景多写点、复杂场景省心」。JPA 做增删改查确实快（方法名查询），但一旦遇到复杂查询、性能问题，Hibernate 的复杂机制反而成了负担；MyBatis 虽然 CRUD 要多写 SQL，但行为透明、没有意外，复杂场景也能从容应对。这也是为什么很多团队「简单项目用 JPA、复杂高并发项目用 MyBatis」。

五、缓存与跨数据库能力

两个次要但常考的维度：

缓存：
  Hibernate：缓存体系强大——一级缓存（Session 级）、二级缓存（SessionFactory 级）、
             查询缓存，配合脏检查，缓存能力是它的强项
  MyBatis：也有一级缓存（SqlSession 级）、二级缓存，但二级缓存在生产中常被禁用
           （分布式下缓存一致性问题），缓存不是它的强项

跨数据库：
  Hibernate：改一下方言（Dialect）配置，同一套代码能跑不同数据库（SQL 自动生成）
             → 跨数据库能力强
  MyBatis：SQL 是手写的，换数据库要改 SQL（不同库语法不同）
           → 跨数据库能力弱（但实际项目很少真的换数据库）

Hibernate 的缓存和跨数据库能力更强，源于它「全自动、屏蔽底层」的定位——因为它管着 SQL 生成，就能顺便管缓存和方言适配。MyBatis 因为「SQL 交给你」，这两块就弱一些。但实践中：「跨数据库」在多数项目里是个伪需求（很少真的换库），而「缓存」现在多用 Redis 等外部缓存而非 ORM 内置缓存。所以这两点的实际影响，往往没有理论上那么大。

六、选型总结与 MyBatis-Plus

选型不是「谁更好」，而是「哪个更适合你的场景」：

场景	推荐
高并发、大数据量、SQL 要精细优化	MyBatis（SQL 可控）
复杂查询、报表、多表关联	MyBatis（SQL 灵活）
简单 CRUD 为主、追求开发速度	Hibernate/JPA（几乎零 SQL）
需要跨多种数据库	Hibernate/JPA（方言适配）
团队熟悉、快速原型	看团队技术栈

一个补充：MyBatis-Plus 是 MyBatis 的增强工具，它给 MyBatis 补上了「简单 CRUD 也不用写 SQL」的能力（内置通用 Mapper，selectById、insert 等开箱即用），相当于「MyBatis 的可控 + 类似 JPA 的 CRUD 便利」的结合。所以现在国内很多项目用 MyBatis-Plus——简单 CRUD 用它内置方法（省事），复杂查询自己写 SQL（可控），两全其美。这也是「MyBatis 生态弥补开发效率短板」的体现。

记忆钩子：「Hibernate 全自动 ORM（帮你写 SQL、屏蔽 SQL、开发快跨库好但 SQL 不可控、学习曲线陡）；MyBatis 半自动（你写 SQL、掌控 SQL、灵活易优化但要手写、跨库弱）；国内大厂偏爱 MyBatis 因高并发要 SQL 可控；MyBatis-Plus 补上 CRUD 便利」。

七、常见误区与追问

误区：MyBatis 半自动说明它比 Hibernate 落后。 恰恰相反——「SQL 可控」在高并发场景是优势，能精确优化每条 SQL，这正是国内大厂偏爱 MyBatis 的原因。
误区：Hibernate 一定比 MyBatis 开发快。 简单 CRUD 是，但复杂查询、性能优化时 Hibernate 的自动 SQL 反而难控制、难优化，MyBatis 更从容。
误区：MyBatis 不能自动生成 CRUD。 原生要写 SQL，但 MyBatis-Plus 增强后内置通用 Mapper，简单 CRUD 也不用写 SQL，兼顾便利和可控。
误区：跨数据库是选 Hibernate 的强理由。 实际项目很少真换数据库，是个常被高估的伪需求；SQL 可控性和优化能力对多数高并发项目更重要。
追问：为什么国内互联网偏爱 MyBatis？ 高并发大数据量场景 SQL 性能是生命线，要能精确控制和优化 SQL；MyBatis 的 SQL 完全在开发者手里，慢查询易定位易优化，而 Hibernate 自动生成的 SQL 难精确控制。
追问：Hibernate 的学习曲线为什么陡？ 要理解对象状态（瞬时/持久/游离）、一二级缓存、脏检查、flush 时机、懒加载、级联、N+1 等一堆机制，概念多且容易踩坑（如 LazyInitializationException）。
追问：MyBatis-Plus 和 MyBatis 什么关系？ MyBatis-Plus 是 MyBatis 的增强工具（非替代），补上了通用 CRUD（内置 Mapper 免写 SQL）、条件构造器、分页等，让简单操作省事、复杂查询仍可手写 SQL。

八、加强记忆

MyBatis 和 Hibernate 代表持久层的两种哲学：Hibernate（JPA）是「全自动 ORM」——「帮你写 SQL、屏蔽 SQL」，你操作对象它自动生成 SQL，简单 CRUD 开发飞快、跨数据库好、缓存强，但代价是 SQL 不可控（复杂查询和优化困难）、学习曲线陡（对象状态/缓存/懒加载/N+1 一堆机制）；MyBatis 是「半自动 SQL 映射」——「让你写 SQL、掌控 SQL」，SQL 自己写、框架只负责参数绑定和结果映射，介于纯 JDBC 和 Hibernate 之间，SQL 完全可控（灵活、易优化、慢查询易定位）、概念简单行为透明，代价是要手写 SQL、跨库弱。核心结论：「SQL 可控」在高并发大数据量场景是优势而非落后，所以国内互联网大厂普遍用 MyBatis（SQL 性能是生命线，必须能精确优化）；Hibernate 更适合简单 CRUD、追求开发速度、对性能不极致的场景。MyBatis-Plus 补上了通用 CRUD 免写 SQL 的便利，让 MyBatis「简单省事、复杂可控」两全。一句话「Hibernate 全自动屏蔽 SQL（快但不可控）、MyBatis 半自动掌控 SQL（灵活易优化），大厂爱 MyBatis 因 SQL 可控，MyBatis-Plus 补 CRUD 便利」。

简化版

详细版