请写一篇关于【MyBatis基础教程：Java持久层框架入门】的技术文章

作者注：我是老张，32岁，在某一线大厂干了6年Java开发。去年十月被“优化”后，裸辞三个月，跳槽涨薪到22k，现在在一家中型互联网公司做后端主力。最近和老婆商量要不要回老家三线城市定居——房租从北京的5800降到1800，但技术氛围可能不如一线。这篇文章写于上周五晚上11点，刚哄睡孩子，泡了杯速溶咖啡，想聊聊一个看似基础、却让我吃过亏又捡过便宜的老朋友：MyBatis。

---

一、那天凌晨三点，我差点删库跑路

那是2021年的一个深夜，我还在上一家大厂做订单系统重构。项目用了新框架——Spring Data JPA，理由很“高大上”：“JPA更面向对象，代码更简洁，符合DDD思想”。

结果上线第三天，运营同事急吼吼打来电话：“老张！用户投诉说查不到历史订单，数据好像丢了！”

我睡眼惺忪地爬起来，连上生产环境日志，一看傻眼了：JPA 自动生成的 SQL 居然把 LEFT JOIN 写成了 INNER JOIN，导致部分关联状态为空的订单直接被过滤掉了。更要命的是，这个 bug 在测试环境根本没复现——因为测试数据太“干净”了。

我一边改代码一边冒冷汗，心里直骂：“早知道就用 MyBatis 了！至少 SQL 是我自己写的，锅也是明明白白的。”

那晚之后，我对“全自动 ORM 框架”产生了深深的怀疑。不是说 JPA 不好，而是——当业务逻辑和数据模型复杂到一定程度，你需要的是可控性，而不是“魔法”。

---

二、MyBatis 是啥？为什么它适合“怕背锅”的程序员？

简单说，MyBatis 是一个半自动化的 Java 持久层框架。它不像 Hibernate 或 Spring Data JPA 那样试图完全隐藏 SQL，而是让你自己写 SQL，但它帮你搞定参数绑定、结果映射这些脏活累活。

举个例子：

// Mapper 接口
public interface UserMapper {
    @Select("SELECT * FROM user WHERE id = #{id}")
    User selectUserById(Long id);
}

就这么几行，MyBatis 自动把 #{id} 替换成安全的预编译参数，再把查询结果映射成 User 对象。你既掌控了 SQL（性能、逻辑清晰），又不用手动写 ResultSet 解析（省下90%的样板代码）。

对比一下几个主流选择：

框架	自动化程度	学习曲线	调试难度	适合场景
JDBC 原生	极低	简单但繁琐	极高（全是手写）	教学/极简项目
MyBatis	中等（半自动）	中等	中（SQL可见）	复杂业务、高可控需求
Spring Data JPA	高（全自动）	陡峭	高（SQL黑盒）	快速原型、CRUD为主
Hibernate	极高	很陡	很高	复杂对象模型、跨数据库

我在大厂六年，见过太多团队为了“先进”而选 JPA，结果上线后遇到 N+1 查询、懒加载失效、SQL 无法优化等问题，最后还得手写 native query —— 那还不如一开始就用 MyBatis。

---

三、别小看“基础”，我靠它在跳槽面试翻了盘

去年被裁员后，我投了20多家公司，有家做本地生活服务的创业公司终面时，技术总监问我：“你们之前系统用什么 ORM？”

我说：“主系统用 MyBatis Plus，但核心交易模块还是原生 MyBatis，因为要精细控制 SQL。”

他眼睛一亮：“那你手写一个带动态条件的查询 SQL，比如根据 name、status、createTime 范围筛选用户。”

我当场在白板上写了：

<select id="selectUsers" resultType="User">
  SELECT * FROM user
  <where>
    <if test="name != null and name != ''">
      AND name LIKE CONCAT('%', #{name}, '%')
    </if>
    <if test="status != null">
      AND status = #{status}
    </if>
    <if test="startTime != null">
      AND create_time >= #{startTime}
    </if>
    <if test="endTime != null">
      AND create_time &lt;= #{endTime}
    </if>
  </where>
</select>

他点点头：“很好，至少你没被‘全自动’惯坏。”

后来 HR 告诉我，他们之前招了个只会用 JpaRepository 的人，结果连一条带子查询的报表都写不出来，运营天天催数据，开发只能半夜爬起来加字段。

你看，运营要的是数据，不是“优雅的对象模型”。而 MyBatis，恰恰是连接 Java 代码和运营需求的桥梁。

---

四、真实场景：当“运营临时改需求”，MyBatis 救了我

上个月，我们上线了一个营销活动配置后台。原本设计很简单：活动表 + 规则表，一对多。

结果上线第二天，运营老大找到我：“老张，能不能让活动支持‘按用户标签分组’？比如 VIP 用户看到 A 活动，普通用户看到 B 活动。”

我内心 OS：“这特么不是要加关联表+复杂查询吗？”

如果用 JPA，我得重新建实体关系、配 FetchType、处理级联，搞不好还要重写整个 Repository。但用 MyBatis？我只花了两小时：

1. 新建一张 activity_user_tag 关联表
2. 在原有 XML 里加一段 <foreach> 动态拼接 IN 条件
3. Service 层加个 tagIdList 参数

搞定。运营当天下午就用上了，还发了个红包感谢我。

在互联网公司，需求变更是常态。MyBatis 的“SQL 可见性”让你能快速响应，而不是被框架束缚住手脚。

---

五、回老家？MyBatis 可能是我技术兜底的底气

最近和老婆认真聊了回老家的事。她担心：“三线城市技术栈会不会太老旧？你这身 MyBatis 技术还有用吗？”

我说：“恰恰相反！一线城市可能玩微服务、云原生，但老家很多企业还在用单体架构 + MySQL。MyBatis 这种成熟、稳定、文档全的框架，反而是中小公司的首选。”

而且，MyBatis 的学习成本低，社区活跃，遇到问题 Stack Overflow 上一搜就有答案。不像某些新潮框架，文档稀烂，出了问题只能看源码——这对于资源有限的小团队太重要了。

更重要的是，MyBatis 让你保持对数据库的敏感度。无论在哪，只要你会写高效 SQL、懂索引优化、能看执行计划，你就不会被淘汰。

---

六、给新手的真心建议：别跳过“基础”，它是你的护城河

如果你是刚入行的 Java 小白，我强烈建议你：

1. 先学原生 MyBatis，再考虑 MyBatis Plus
   Plus 很香（自动生成 CRUD），但底层原理不懂，遇到复杂查询照样抓瞎。

2. 一定要手写 XML，别只用注解
   注解适合简单 SQL，但动态 SQL、多表关联、批量操作，XML 才是王道。

3. 学会看 MyBatis 日志
   开启 log4j.logger.org.apache.ibatis=DEBUG，亲眼看看它生成的 SQL 和参数，这是调试的黄金法则。

4. 别迷信“全自动”
   记住：ORM 的目标不是消灭 SQL，而是让你更高效地使用 SQL。

---

结尾：技术之外，是选择

写这篇 MyBatis 教程，其实不只是教你怎么写 XML。我想说的是：在技术选型上，务实比时髦更重要；在职业发展上，适应力比光环更长久。

我可能下个月就搬回老家了。房租省下4000，孩子能上公立幼儿园，父母也能帮忙带娃。技术上，我不指望再搞什么高并发秒杀，但只要能把业务逻辑理清楚、把 SQL 写明白、让运营同事少催几次——我觉得，这就是价值。

MyBatis 教会我的，从来不是“如何连接数据库”，而是：在不确定的世界里，抓住你能控制的那一部分。

就像那句老话：你永远不知道明天是裁员通知，还是老家的 offer。但只要你手里的 SQL 写得稳，心里就不慌。

共勉。

—— 老张，于北京出租屋，2024年6月