【后端】【Java】一文详解为什么互联网公司更偏向 MyBatis，而不是 JPA？

  • Home
  • 技巧教学
  • 【后端】【Java】一文详解为什么互联网公司更偏向 MyBatis，而不是 JPA？
by admin技巧教学

为什么大多数互联网公司更偏向 MyBatis，而不是 JPA？

为什么互联网公司更偏向 MyBatis，而不是 JPA？

在很多互联网公司（阿里系、字节、腾讯、美团等）中，你会发现一个现象：

👉 核心业务系统几乎清一色用 MyBatis（或 MyBatis Plus）

👉 JPA 更多出现在中小项目、后台系统或内部工具

这并不是“JPA 不好”，而是 互联网公司的技术诉求，天然更匹配 MyBatis。

下面我们从多个维度拆解这个选择背后的原因。

一、互联网业务的本质：复杂 SQL + 极致性能

1️⃣ 互联网业务不是“CRUD 为主”

互联网系统常见特点：

数据量大（千万 / 亿级）

SQL 复杂（多表 join / 子查询 / 聚合）

报表、推荐、统计频繁

性能要求极高（毫秒级）

📌 而这些，正是 JPA 的“非舒适区”

2️⃣ MyBatis 是“SQL 驱动”的框架

MyBatis 的设计哲学：

SQL 是一等公民

👉 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）