【后端】【Java】一文详解为什么互联网公司更偏向 MyBatis，而不是 JPA？
为什么大多数互联网公司更偏向 MyBatis，而不是 JPA？
为什么互联网公司更偏向 MyBatis，而不是 JPA？
在很多互联网公司（阿里系、字节、腾讯、美团等）中，你会发现一个现象：
👉核心业务系统几乎清一色用 MyBatis（或 MyBatis Plus）
👉JPA 更多出现在中小项目、后台系统或内部工具
这并不是“JPA 不好”，而是互联网公司的技术诉求，天然更匹配 MyBatis。
下面我们从多个维度拆解这个选择背后的原因。
一、互联网业务的本质：复杂 SQL + 极致性能
1️⃣ 互联网业务不是“CRUD 为主”
互联网系统常见特点：
数据量大（千万 / 亿级）
SQL 复杂（多表 join / 子查询 / 聚合）
报表、推荐、统计频繁
性能要求极高（毫秒级）
📌而这些，正是 JPA 的“非舒适区”
2️⃣ MyBatis 是“SQL 驱动”的框架
MyBatis 的设计哲学：
SQL 是一等公民
<select> select u.id, u.name, count(o.id) orderCount from user u left join order o on u.id = o.user_id where u.status = 1 group by u.id </select>👉 SQL 怎么写，数据库就怎么跑
👉执行计划可控、性能可预测
二、性能“可控性”是互联网公司的第一优先级
1️⃣ MyBatis 的性能是“显式”的
SQL 明确
是否走索引清清楚楚
一条方法 = 一条 SQL
📌 出问题时：
看 SQL
看执行计划
看索引
定位路径非常短
2️⃣ JPA 的性能是“隐式”的
save(entity);背后可能发生：
select
update
flush
cascade
dirty check
📌你没写 SQL，但 SQL 已经跑了
在高并发场景：
问题难复现
行为难预测
调优成本极高
三、复杂 SQL 在 JPA 中是“灾难级体验”
1️⃣ JPQL / Criteria API 可读性差
CriteriaBuilder cb = em.getCriteriaBuilder();📌 实话实说：
可读性差
学习成本高
调试困难
对比 MyBatis：
select * from order where status = 1 limit 100👉SQL 即文档
2️⃣ JPA 难以表达数据库特性
JPA 的目标是：
屏蔽数据库差异
但互联网公司恰恰要用：
MySQL 索引 Hint
分库分表语法
特定函数
自定义优化 SQL
📌 MyBatis：直接写
📌 JPA：绕路 or 放弃
四、团队协作：MyBatis 更符合“大团队工程化”
1️⃣ 前后端 / DBA / 后端协作成本
在互联网公司：
DBA 会 review SQL
架构师关注执行计划
后端关注代码结构
📌 MyBatis：
SQL 明文
所有人都能看懂
📌 JPA：
SQL 运行时生成
DBA 无法提前介入
2️⃣ MyBatis 更利于代码评审（CR）
<select id="listHotUsers">SQL 是否合理，一眼可见
是否有索引，一看就知道
JPA：
findByUserStatusAndCreateTimeBetween()👉你得脑补 SQL
五、互联网公司更害怕“不可预期行为”
JPA 的几个高危点
| 风险 | 说明 |
|---|---|
| N+1 查询 | 一不小心就炸 |
| 自动 flush | 查询前偷偷 update |
| 脏检查 | CPU 消耗不可控 |
| 级联 | save 引发雪崩 |
| 懒加载 | 线上常见事故 |
📌 这些问题：
不是“写错”
而是“没意识到”
👉互联网公司更倾向“显式控制”
六、历史原因：国内技术栈的演进路径
国内主流路径：
JDBC ↓ MyBatis ↓ MyBatis-Plus大量老系统
大量 SQL 资产
成熟的使用规范
完整的最佳实践
📌 切换到 JPA 的收益不明显，但风险很大
七、JPA 真的不适合互联网吗？
❌ 不是
JPA 非常适合：
后台管理系统
内部工具
小型项目
CRUD 密集型服务
表结构稳定的系统
📌 只是不适合“核心高并发业务”
八、真实的一线最佳实践（非常重要）
MyBatis + JPA 混合使用
JPA：
简单 CRUD
快速开发
MyBatis：
核心链路
复杂 SQL
性能敏感路径
这是很多中大型互联网公司的真实架构选择。