MyBatis 与 Hibernate 有哪些不同？

• 标签：后端、MyBatis

🏛 业务架构师

两者都是 ORM，差异本质是**"SQL 控制权"的取舍**：

• MyBatis（半自动）：SQL 手写、对象映射自动。SQL 可见可控——执行计划、索引配合、慢查询优化都直接下手；SQL review 是显式的；
• Hibernate（全自动）：面向对象操作生成 SQL，HQL/缓存体系完整。CRUD 效率高，但复杂查询生成的 SQL 不可控——N+1 查询、隐式全字段更新这些坑，出问题时排查要深入框架行为；强关联映射在分库分表时也很难施展。

我的选型逻辑按业务场景：

• 高并发、大数据量、性能敏感的互联网交易系统：MyBatis（+ MyBatis-Plus 补齐单表效率）——SQL 就是资产，要握在自己手里。慢了能改 SQL、能上索引、能看执行计划，权责清晰；
• CRUD 密集、并发温和的企业内部系统（ERP、OA、管理系统）：Hibernate/JPA 开发效率优势明显，表关联映射一次定义处处复用；
• 团队基因：国内生态与人才池 MyBatis 占绝对优势，招聘与维护的现实成本也该计入选型——技术选型从来不是纯技术决策。

一个折中趋势：Spring Data JPA 的方法名派生查询 + 复杂场景 @Query 手写，兼顾两端。

提醒一个 MyBatis 的治理点：SQL 散在 XML 里，缺乏统一视角——要配套 SQL 扫描规范（禁 select *、索引命中文档化）和慢 SQL 监控，否则"可控"退化成"散养"。工具给了控制权，还要有行使控制权的流程。

🏗 系统架构师

两者都是 ORM，但抽象层次和设计哲学不同：

• 控制权：MyBatis SQL 与代码分离，SQL 全部手写在 XML/注解，开发者完全掌控每条语句——性能问题可精确定位和调优；Hibernate 是全自动 ORM，面向对象操作自动生成 SQL（HQL/Criteria），开发快但 SQL 生成过程黑盒，复杂查询失控；
• 映射模型：Hibernate 做对象级联、懒加载、一级/二级缓存、脏检查、乐观锁，对象状态管理完整但也重——学习曲线陡，懒加载的 N+1 问题、session 生命周期坑多；MyBatis 只是"SQL 执行结果 → 对象"的映射器，轻量直白；
• 适用场景：互联网高并发、SQL 需要精细优化（分库分表、复杂报表）选 MyBatis；领域模型稳定、CRUD 密集、团队 OOP 能力强的企业内部系统（ERP）选 Hibernate/JPA 更省代码。

我的选型实践：国内互联网主流是 MyBatis（或 MyBatis-Plus），因为流量大、SQL 优化是刚性需求、DBA 要审 SQL。MyBatis-Plus 补齐了单表 CRUD 的效率短板（条件构造器、代码生成），等于"手写复杂 SQL + 自动单表操作"两全。而 JPA 在海外与 Spring 生态里依旧强势。选型本质是问：SQL 决策权要不要留给团队。

💻 全栈开发专家

定位差异：MyBatis 半自动（SQL 自己写），Hibernate 全自动 ORM（操作对象，HQL/ criteria 生成 SQL）。

维度	MyBatis	Hibernate
SQL 控制	完全可控，调优自由	生成 SQL，复杂查询难干预
学习/维护	简单直观，SQL 可见	门槛高（缓存/延迟加载/状态机）
复杂查询/多表	SQL 直写，轻松	HQL 很绕
数据库移植	弱（SQL 方言）	强（方言抽象）
开发效率	单表要手写（或 MyBatis-Plus）	全自动，CRUD 快
OOM 风险	结果集可控	一对多/延迟加载易踩坑

国内现实：MyBatis（+ MyBatis-Plus 补单表效率）是绝对主流，因为互联网业务 SQL 调优诉求 > 移植性诉求，DBA 和开发都要看得见 SQL。

我的选型经历：C 端高并发服务用 MyBatis——深分页、批量、索引 hint 都要精确控制；内部 ERP 类小系统试过 JPA（Hibernate），CRUD 省事但每次性能排查都要翻生成的 SQL，最后团队还是统一回 MyBatis-Plus。

共通的坑：一级缓存语义（Spring 集成下的失效）、#{} 预编译防注入、动态 SQL 的 OOM 级拼接——这两个框架层面的事我都单独整理过 checklist。