如果说 ORM 是“对象如何存在于数据库中的体系”，
那 MyBatis，就是这套体系中最靠近数据库的一条工程路线。
这一篇不讲 XML 怎么写，不讲分页插件，不教 CRUD。
我们只回答一个问题：
👉 为什么 JDBC 一定会进化出 MyBatis？
一、JDBC 在干什么？——最原始的数据访问形态
在 JDBC 时代，后端访问数据库，几乎是纯手工劳动：
- 手写 SQL
- 手写参数绑定
- 手写结果映射
- 手写连接与事务管理
一个最普通的查询，至少包含四类代码：
- SQL 拼接
- 参数处理
- 执行与异常
- 对象封装
本质上，每个项目都在重复造这套轮子。
👉 JDBC 从来不是“ORM”，它只是：
数据库通信协议的 Java 封装。
二、JDBC 的真实痛点（不是“麻烦”，是“不可工程化”）
如果只是“代码多”，其实不是大问题。
真正致命的是：JDBC 让 SQL 难以工程化。
典型问题包括：
1️⃣ SQL 分散，无法管理
- 写在代码里
- 拼在字符串中
- 逻辑和业务混在一起
👉 结果：无法复用、无法规范、无法审计。
2️⃣ 映射逻辑高度重复
- ResultSet → Object
- null 处理
- 类型转换
👉 每个项目都在造“半吊子 ORM”。
3️⃣ 动态 SQL 不可维护
- if 拼字符串
- 参数错位
- SQL 注入风险
👉 可读性、可维护性、可演进性极差。
4️⃣ 数据访问层无法沉淀为“基础设施”
你几乎不可能：
- 给 JDBC 层统一加审计
- 统一分页
- 统一慢 SQL 监控
- 统一加密/脱敏
👉 因为 JDBC 太原始。
三、MyBatis 出现：不是 ORM，而是“SQL 工程化框架”
MyBatis 的诞生目标非常清晰：
👉 把 JDBC + SQL 这件事，升级为“工程能力”。
它做的核心事情，其实只有四类：
✅ 1. SQL 结构化管理
- XML / 注解集中管理
- 与 Java 接口绑定
- 形成可治理资产
✅ 2. 参数绑定标准化
#{}预编译- 类型自动转换
- 安全防注入
✅ 3. 结果映射自动化
- ResultMap
- 驼峰映射
- 嵌套结构支持
👉 JDBC 时代最大工作量，直接消失。
✅ 4. 动态 SQL 语言化
- if / choose / foreach / trim
- SQL 从“字符串”，变成“结构语言”
👉 这是 MyBatis 的工程价值核心之一。
四、Mapper 接口：MyBatis 最关键的抽象
MyBatis 真正改变工程形态的，不是 XML，是：
👉Mapper 接口
UserMapper.findById(Long id)这一层的出现，意味着：
- 数据访问层开始“接口化”
- SQL 与业务解耦
- Repository 模式自然形成
Mapper 的本质是：
SQL 的“函数签名”。
这一步，让数据库访问第一次具备了：
- 可替换性
- 可测试性
- 可治理性
👉 这是 JDBC 永远做不到的
五、MyBatis 的本质定位（非常重要）
从系统层级看，MyBatis 从来不是完整 ORM。
它没有：
- 对象生命周期
- 脏检查
- 一级缓存体系
- 关系自动管理
它只关心：
👉一条 SQL，如何优雅地执行，并把结果翻译成对象。
所以一个非常准确的定位是：
MyBatis 是 SQL Mapper，不是 ORM 引擎。
也正因为如此：
- 性能路径清晰
- 行为完全可控
- 但工程责任在开发者
六、为什么 MyBatis 天然依赖数据库能力
用 MyBatis，本质是把这件事交给你：
- SQL 设计权
- 索引设计权
- Join 策略
- 锁与事务粒度
框架不会替你兜底：
- 不会防 N+1
- 不会防慢 SQL
- 不会自动批量
- 不会理解业务关系
👉 MyBatis 放大能力，也放大短板。
所以它更适合：
- 有 DBA / 数据库专家的团队
- 对性能路径高度敏感的系统
- 报表、统计、核心链路
七、MyBatis 在真实企业中的位置
在大多数中大型系统里，MyBatis 很少“单独存在”，而是：
- 作为复杂查询层
- 作为核心数据通道
- 作为性能兜底方案
常见结构是：
- JPA 管业务对象
- MyBatis 管复杂 SQL
👉 MyBatis 往往出现在：
“系统最怕慢、最怕错、最怕炸”的地方。
八、本篇你应该真正带走的认知
这篇不要求你会用 MyBatis，但你必须形成几个判断：
- MyBatis 的核心价值是“SQL 工程化”
- 它解决的是 JDBC 的工程不可控
- 它不是 ORM 引擎
- 它要求数据库工程能力
- 它更像“数据库工程路线”
（支持资料、图片参考_相关定制）_文章底部可以扫码)
