企业官网建设流程全解析

聊 MyBatis 这件事，在 Java 开发圈子里几乎避不开。作为当前国内使用频率极高的 ORM 持久层框架，MyBatis 靠着“灵活、可控、SQL 自由”这几个特性，长期占据着 Java 后端技术栈的重要位置。不管你是刚学 Java 的新手，还是准备跳槽的老兵，面试题里大概率会碰到“MyBatis 一级缓存和二级缓存区别”“#{} 和 ${} 的区别”“MyBatis 和 Hibernate 怎么选”这些问题。这篇内容就把 MyBatis 从入门到实战的关键点完整梳理一遍，包含核心架构、Spring Boot 整合步骤、缓存机制、常见坑点排查，适合正在学习 Java 或者准备面试的同学做系统性参考，也适合那些已经在用 MyBatis 但想深入理解原理的开发者在闲暇时读一读。

1. 先搞清楚 MyBatis 是什么（顺便聊聊 ORM 这回事）

1.1 从 JDBC 到 MyBatis，到底解决了什么问题

很多人接触 MyBatis 之前，先写过 JDBC 代码。说句实话，用 JDBC 操作数据库，流程本身并不复杂，就是注册驱动、获取连接、创建 Statement、执行 SQL、处理结果集、关闭连接这些步骤。真正的痛点在于，这些步骤里掺杂了大量样板代码——每次都要手动处理资源释放，手动把 ResultSet 里的字段一个个塞进 Java 对象，手动处理 SQL 参数。

想象一下，你有一个 User 表，字段有 id、name、age、email、create_time，查询一条用户记录后要转换成 User 对象，rs.getString("name")、rs.getInt("age")这种代码得写好几行。如果表有几十个字段，写完这段代码基本就是在做体力劳动。而且如果你用的是 JDBC 原生 API，SQL 语句是散落在 Java 代码里的，后期想优化一条 SQL，得翻半天代码，维护性很差。

MyBatis 干的活，本质上就是把“JDBC 手动操作”的重复部分抽出来，把 SQL 从 Java 代码里解耦出去。你需要做的就是定义接口方法、写 SQL（放在 XML 或注解里）、配置好返回类型，MyBatis 在底层替你把连接管理、参数绑定、结果集映射这些脏活累活全干了。这里的“半自动”也由此而来——SQL 是你自己写的，MyBatis 只负责执行，这跟 Hibernate 那种全自动 ORM 框架完全生成 SQL 的方式有本质区别。

1.2 为什么说 MyBatis 不是严格意义的 ORM 框架

关于“ORM”这个说法，很多人有误区。Hibernate 那种把数据库表直接映射成 Java 对象的框架，叫 ORM 没什么问题。但 MyBatis 骨子里是“SQL Mapping”框架，它做的事情更像是“把 SQL 语句和 Java 方法建立映射关系”，而不是“把表映射成对象”。你可以自由控制 SQL 的每个细节，表关联、子查询、复杂条件、多表 join，这些操作在 MyBatis 里有着极高的自由度，但在 Hibernate 里你可能得研究怎么写 HQL 或者 Criteria 查询。

这个差异也决定了选型方向。如果你的项目里有大量复杂查询、报表类 SQL、多表关联，MyBatis 会让你写得很痛快，因为 SQL 本身就是你熟悉的数据库方言，执行计划可控、容易优化。如果你主要做标准增删改查、而且对象模型与数据库结构映射比较规整，Hibernate 的自动化程度确实能帮你省下不少工作。但现实是国内互联网公司，绝大多数业务系统查询条件灵活多变，MyBatis 这种风格更契合“SQL 掌握在开发手中”的思路。

1.3 一个最小认知模型：框架解决的三个问题

学习 MyBatis，只要抓住三条主线就不会乱。第一条是“连接怎么管理”，MyBatis 通过数据源连接池解决，你只要在配置文件里指定 driver、url、username、password，框架自动从池里取连接、归还连接。第二条是“SQL 怎么执行”，MyBatis 内置了 SQL 解析、参数映射、结果集映射等一整套机制，你传一个对象进去，框架会按#{}占位符把对象属性绑定到 PreparedStatement 参数上。第三条是“对象怎么映射”，MyBatis 会把查询结果自动映射成你指定的实体类，靠的是 resultType 或 resultMap 配置。

这三条线正好对应 MyBatis 的三大核心对象：SqlSessionFactory负责创建会话（连接管理）、MappedStatement负责记录 SQL 和参数映射关系、ResultSetHandler负责结果集到对象的转换。入门阶段先不用深入源码，把这三个概念记住，后续看任何 MyBatis 资料都会轻松得多。

2. 核心原理拆解：MyBatis 运行起来到底发生了什么

2.1 SqlSessionFactory 和 SqlSession，从构建到执行的全过程

MyBatis 的运行入口非常统一，所有操作都必须先经过SqlSessionFactory。这个工厂是重量级对象，构建一次、全局复用，项目启动阶段通过SqlSessionFactoryBuilder读取配置文件（mybatis-config.xml）创建出来。配置工作包括数据源、事务管理器、类型别名、插件等，框架会把 XML 里的内容解析成Configuration对象，这个对象保存了 MyBatis 的全部运行状态。

随后每次数据库操作，都从SqlSessionFactory.openSession()得到一个SqlSession。注意这里就是日常所说的“会话”，它对应一次数据库连接资源，底层包装着Executor——真正执行 JDBC 操作的人。SqlSession 提供了 selectOne、selectList、insert、update、delete 等方法，你在 Mapper 接口里定义的每个方法，本质上都是通过 SqlSession 对应方法转发的。

这套设计其实解决了一个常见问题：数据库连接是稀缺资源，不能每次都新建，也不能长期占用不释放。所以 SqlSession 在使用完毕后必须关闭，正常情况下在 finally 块中处理或者交给 Spring 管理。很多初学者在 MyBatis 单独使用时，忘了关闭 SqlSession，结果连接池被耗尽，应用卡死，这是第一个需要注意的坑。

2.2 Mapper 接口背后的动态代理魔法

用过 MyBatis 的人都知道，Mapper 只是一个接口，没有实现类，但你直接@Autowired就能注入使用。这个神奇效果靠的是 JDK 动态代理。MyBatis 启动时扫描 Mapper 接口，给每个接口生成一个代理对象，这个代理对象实现了接口的全部方法。当你调用userMapper.selectById(1)时，代理对象拦截方法调用，从方法名、参数类型中查找对应的MappedStatement（里面封装了 SQL 和映射规则），然后交给 SqlSession 执行。

整个过程其实可以理解为“约定优于配置”：接口方法名要跟 XML 中 namespace 下的 statement id 对应，参数要能被 MyBatis 识别，返回类型要能被正确映射。这也是为什么 XML 里namespace必须写接口全限定名，不然启动就会报错BindingException。从框架设计角度看，这层动态代理机制把强类型接口和自由 SQL 很好地桥接起来，既让调用方感觉不到底层代理的存在，也保留了 SQL 的灵活性。

2.3 揭开四大组件的面纱：Executor、StatementHandler、ParameterHandler、ResultSetHandler

MyBatis 的源码里，一条 SQL 从发起到底层执行，要经过四个核心组件。Executor是顶层调度者，负责缓存管理、事务管理和 SQL 执行流程的协调；StatementHandler负责创建 JDBC 的 Statement，并在执行前绑定参数、执行后处理结果；ParameterHandler专门负责把 Java 参数转换成 JDBC 类型参数；ResultSetHandler负责把 JDBC 返回的 ResultSet 转换成 Java 对象或集合。

看起来复杂，但你只需要明白一件事：MyBatis 的插件机制（拦截器）能对这四个组件做动态代理增强。比如分页插件 PageHelper 就是拦截Executor的 query 方法，在 SQL 执行前拼上 limit 语句。如果你未来想研读 MyBatis 源码，从这四个组件入手是最佳路径，搞懂它们各自的职责，整个框架的骨架就全清楚了。

3. Spring Boot 整合 MyBatis 实操：从零搭建一套完整配置

3.1 引入依赖与基础配置（版本选择很关键）

现在做 Java 项目基本离不开 Spring Boot。整合 MyBatis 的步骤不算复杂，我直接给出可复制的方案：

<dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>

注意版本兼容问题。Spring Boot 2.x 对应 mybatis-spring-boot-starter 2.x，Spring Boot 3.x 则要用 mybatis-spring-boot-starter 3.x（目前主流是 3.0.3 以上版本）。如果版本没对齐，容易出现Invalid bean definition之类的启动异常。

application.yml 里的关键配置如下：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/test_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.demo.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

mapper-locations指定 XML 文件位置，type-aliases-package让实体类可以使用短类名，map-underscore-to-camel-case: true是必须建议开启的配置——它能把数据库的create_time字段自动映射成 Java 的createTime，省去大量 resultMap 配置。log-impl则把 SQL 日志输出到控制台，调试时非常有用。

3.2 Mapper 接口与 XML 的编写规范（附示例代码）

首先定义实体类和 Mapper 接口：

public class User { private Long id; private String name; private Integer age; private String email; // getter/setter 省略 } @Mapper public interface UserMapper { User selectByPrimaryKey(Long id); List<User> selectByCondition(@Param("name") String name, @Param("age") Integer age); }

然后在 resources/mapper/UserMapper.xml 里写 SQL：

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.example.demo.mapper.UserMapper"> <select id="selectByPrimaryKey" resultType="User"> SELECT id, name, age, email FROM user WHERE id = #{id} </select> <select id="selectByCondition" resultType="User"> SELECT id, name, age, email FROM user <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="age != null"> AND age = #{age} </if> </where> </select> </mapper>

特别注意#{}和${}的区别。#{}在底层通过 PreparedStatement 参数占位符传值，会做预编译处理，安全性好，能防止 SQL 注入，绝大多数场景都用它。${}是字符串直接拼接，无法防止 SQL 注入，只适合在需要动态指定表名、列名、排序字段时使用。说个我自己踩过的坑：早期做分页排序时，用了${orderColumn}直接拼接列名，用户传了id; drop table user这种输入，差点出大问题。后来全部改为白名单校验，只有白名单内的列名才允许作为排序字段。

3.3 动态 SQL 的常用玩法：if、where、set、foreach

动态 SQL 算是 MyBatis 最吸引人的特性之一。以前的写法是 Java 层拼接 SQL 字符串，有了动态 SQL，这类工作全挪到 XML 里完成。

<if>用于条件判断，<where>会自动去掉 SQL 中多余的前缀（比如AND或OR），<set>专门处理更新语句中那些需要动态决定是否更新的字段，<foreach>是批量操作的灵魂，常用于 IN 查询和批量插入。

<insert id="batchInsert"> INSERT INTO user (name, age, email) VALUES <foreach collection="list" item="item" separator=","> (#{item.name}, #{item.age}, #{item.email}) </foreach> </insert>

实际项目里，我建议动态 SQL 优先在 XML 中实现，不要图省事故意把逻辑写在 Java 代码里。原因很简单，SQL 变更登记和审核在 XML 里一目了然，代码 review 的时候能快速定位问题。当然过度使用动态 SQL 也会造成 XML 膨胀，如果出现五六层嵌套的 if 判断，就该考虑拆 SQL 了。

4. 缓存机制深挖：一级缓存和二级缓存实战解析

4.1 一级缓存的默认生效条件

MyBatis 的一级缓存是 SqlSession 级别的，也叫本地缓存，默认开启，无需任何配置。同一个 SqlSession 内，对于同一条 SQL（相同语句 ID、相同参数），第一次查询会放入缓存，第二次查询直接命中缓存，不再访问数据库。

这里就出现了经典面试题：“MyBatis 一级缓存失效场景有哪些”。答案是：SqlSession 不同则缓存不同；SqlSession 内执行了任意增删改操作，缓存会被清空（因为数据可能发生了变化）；查询参数不同，缓存 key 不同；手动调用了clearCache()方法。还有一个注意点——在 Spring 整合环境中，如果没有开启事务，每次 Mapper 操作都会新建一个 SqlSession，此时一级缓存基本形同虚设。所以千万不要把“一级缓存提升性能”当作核心优化点，它在大多数 Web 项目里只能帮倒忙（避免读到脏数据倒是真的）。

4.2 二级缓存怎么开启，又有哪些坑

二级缓存是 Mapper 级别的，多个 SqlSession 共享。它的实现机制比一级缓存复杂：SqlSession 关闭或提交时，一级缓存的数据会被写入到二级缓存中。需要手动开启，配置三步走：

第一，在 mybatis-config.xml 设置全局配置：

<settings> <setting name="cacheEnabled" value="true"/> </settings>

第二，在具体 Mapper.xml 里添加<cache/>标签：

<cache eviction="LRU" flushInterval="60000" size="512" readOnly="true"/>

第三，查询结果对应的实体类必须实现Serializable接口，因为二级缓存的数据可能通过序列化方式存储。

二级缓存看起来很美，但坑也非常多。最典型的问题是：如果使用 Spring 事务管理，同一个事务里多个 SqlSession 共享数据，可能出现事务 A 查到的数据被缓存，事务 B 修改了数据库，却没有触发缓存失效的情况，读到脏数据。另一个坑是，当执行了多表关联查询时，缓存只跟在执行查询的那个 Mapper 上，另一个 Mapper 改了关联表，缓存不会自动失效。所以我的建议是：默认不要开启二级缓存，绝大多数业务场景下，引入这个缓存带来的问题远大于性能收益。真需要缓存，优先考虑 Redis 做显式缓存，至少可控性更强。

4.3 一段代码看透缓存命中流程

SqlSession session1 = sqlSessionFactory.openSession(); UserMapper mapper1 = session1.getMapper(UserMapper.class); User u1 = mapper1.selectByPrimaryKey(1L); // 第一次查询，访问数据库 User u2 = mapper1.selectByPrimaryKey(1L); // 第二次查询，命中一级缓存 session1.close(); SqlSession session2 = sqlSessionFactory.openSession(); UserMapper mapper2 = session2.getMapper(UserMapper.class); User u3 = mapper2.selectByPrimaryKey(1L); // 未开启二级缓存前，访问数据库 session2.close();

如果开启了二级缓存，在 session1.close() 之后，它的缓存数据会写入二级缓存，session2 第一次查询时如果二级缓存中有数据，就直接命中二级缓存，不再查数据库。整个流程的关键是理解“跨会话缓存”必须在会话关闭或提交后才会生效。

5. 常见问题排查实录：那些年踩过的 MyBatis 坑

问过不少刚接触 MyBatis 的同学，大家遇到的坑高度集中在绑定异常、参数映射、缓存和日志这几个方向。下面把这些问题整理成速查表，并附上排查思路。

5.1 打印 SQL 日志的正确姿势

排查任何 MyBatis 相关问题，打印 SQL 日志永远是第一步。Spring Boot 配置里可以通过mybatis.configuration.log-impl直接指定日志输出。顺带提一句，如果配置了StdOutImpl还是没看到 SQL 日志，先检查mappers是否真的被加载——启动日志里会打印加载的 mapper XML 列表，如果为空，说明路径没对。

更精细的方式是配置 logback 的 logger 级别：

<logger name="com.example.demo.mapper" level="trace"/>

这样只有 Mapper 包下的 SQL 会输出，不干扰其他业务日志。输出的内容包含Preparing: SELECT ...（预编译语句）和Parameters: xxx(String)（绑定参数），对照这两条能快速判断 SQL 是否为预期语句、参数是否正确。

5.2 批量插入的性能优化解法

通常写法是用<foreach>一次性拼接多条 VALUES，这在小批量（几百条）时效率很高。但数据量过万时，SQL 长度会超过数据库 max_allowed_packet，大概率报错。推荐做法是把 List 分片，例如每 500 条执行一次批量插入。另一种方案是使用ExecutorType.BATCH的 SqlSession，把所有 insert 语句累积到同一个 PreparedStatement，最后统一提交，提升性能的同时也能减少网络往返。

5.3 MyBatis 支持哪几种数据库（顺手解决国产数据库兼容问题）

很多朋友问 MyBatis 能不能支持 GaussDB、达梦、人大金仓这些国产数据库。答案是可以，MyBatis 本质上不绑定任何数据库，它操作的是 JDBC 驱动，只要驱动和方言写对，什么库都能跑。真正让人头疼的其实是 SQL 方言差异——比如 MySQL 的LIMIT、Oracle 的ROWNUM、达梦的TOP，这些在 XML 里写死了，切库时得逐个改。为了降低这种切换成本，一种常见的做法是把分页、日期函数封装成自定义方言类，或者直接用支持方言的数据库分页插件对多数据库适配。

6. MyBatis 与 MyBatis-Plus、Hibernate 的取舍思考

6.1 流行搭配：MyBatis-Plus 到底香不香

说到 MyBatis，几乎绕不开 MyBatis-Plus。它的出现就是为了解决 MyBatis 单表 CRUD 需要手写 SQL 的问题。MP 提供BaseMapper接口，内置了selectById、insert、updateById、selectPage等常用方法，单表操作不再需要写 XML，复杂查询还是保留 MyBatis 的动态 SQL 能力。另外 MP 的QueryWrapper、LambdaQueryWrapper用起来很顺手，条件构造可以直接用 Lambda 引用方法名，编译期就能发现字段名错误。

对这个选型我是很认可的，因为它在“灵活”和“效率”之间找到了平衡点。实际项目里，80% 的数据库操作是单表 CRUD，用 MP 能大幅提升开发效率；剩下 20% 的复杂查询，MyBatis 本身的 XML 能力一点不会少。不过也有一个隐含前提：项目组需要对 MP 的约定比较熟悉，比如逻辑删除、乐观锁字段的处理方式，不然用错配置产生的坑也是真实的，比如查数据时自动附加了deleted=0条件，你不知道它的存在，排查起来一头的汗。

6.2 常见选择疑问：什么时候用 Hibernate，什么时候用 MyBatis

选型这块，我给不了统一答案，但可以说一下自己的经验判断。Hibernate 适合对象模型非常清晰、表间关系相对规整、以标准 CRUD 为主的领域模型开发，它能自动维护外键关联、级联操作，开发效率高。但 Hibernate 在复杂查询上的学习成本曲线很陡峭，一旦出现慢 SQL，定位 SQL 来源和执行计划要比 MyBatis 困难不少。MyBatis 恰好在“SQL 可控性”上占优，适合业务复杂、查询灵活、团队熟悉 SQL 的互联网项目。不要盲目迷信“封装程度”，也不要低估 SQL 自由度的价值，从维护性角度来选才是最理性的。

7. 阅读理解扩展：如何从源码角度继续逼近 MyBatis

7.1 读源码的三个入口点

如果 MyBatis 已经用得比较熟练，想深入研究原理，我建议从三个入口点切入。第一个入口是SqlSessionFactoryBuilder.build()，从这里能看到 XML 配置如何一步步解析成 Configuration 对象，涉及 XPath 解析、配置类注册等细节。第二个入口是MapperProxy.invoke()，能理解动态代理如何根据 method 找到 MappedStatement，以及为什么 Mapper 接口不能重载（重载会造成 MappedStatement 映射歧义）。第三个入口是BaseExecutor.query()，能完整看到一级缓存的命中逻辑和二级缓存委托的转移过程。

7.2 拓展知识：MyBatis 插件的执行原理

MyBatis 插件机制是很多高级功能的底座，分页插件、读写分离插件、数据脱敏都建立在它之上。原理是 JDK 动态代理——插件代理 Executor、StatementHandler、ParameterHandler、ResultSetHandler 这四个接口。你通过@Intercepts注解声明要拦截的方法签名，MyBatis 会生成代理链，调用目标方法前先执行拦截逻辑。想写一个能用的插件，关键是要理解拦截的方法参数，比如拦截Executor.query时能得到MappedStatement、参数对象和RowBounds，分页插件就是从这里改 SQL 的。

我自己的建议是：不要一上来就写复杂插件，可以先写一个简单的 SQL 耗时统计插件练手，它天然能锻炼对参数解析和代理链的理解。熟练后，再考虑扩展更复杂的场景，比如做多租户隔离自动拼接条件。

8. 从面试角度再看 MyBatis：高频考点集中串讲

8.1 面试问答得分点整理

如果你在准备 Java 面试，MyBatis 相关的问题几乎必考。我把自己面试别人以及被面试时遇到的典型问题按得分点整理出来：

• #{}和${}的区别，核心要点是预编译与拼接、SQL 注入风险、适用范围。
• 一级缓存与二级缓存机制，得分点是“为什么默认开启一级缓存但形同虚设”以及“二级缓存的失效风险和 Serializable 要求”。
• MyBatis 如何实现 Mapper 接口，得分点是 JDK 动态代理、namespace 绑定、MappedStatement 查找。
• MyBatis 与 Hibernate 的对比，得分点是“半自动 vs 全自动”“SQL 可控性”“复杂查询表现”。
• 分页插件原理，得分点是拦截 Executor、拼接方言、ThreadLocal 传参。

8.2 深度问题：如何保证数据一致性

总有人问到“MyBatis 怎么保证数据一致性”，这个问题其实不在 MyBatis 的职责范围内。MyBatis 只是持久层框架，它的事务管理依赖底层数据库和事务管理器。在 Spring 环境下，通过@Transactional可以让多个 Mapper 操作共享同一个事务；在非 Spring 环境下，需要自己控制SqlSession的提交与回滚。这里面有个经典坑：MySQL 默认隔离级别是可重复读，如果你的方法里先查询、再修改、再查询，第二个查询可能读不到别人已提交的新数据，这跟 MyBatis 没有关系，是数据库隔离级别决定的。理解了这层关系，才能真正把“Java 怎么保证数据一致性”这个问题回答透彻。

我个人在实际操作和带团队时最深的一个体会是：项目开发周期越紧张，“SQL 可控性”的价值就越明显。MyBatis 把 SQL 交给开发者之后，你既是执行者也是负责人，这比把 SQL 生成逻辑交给框架更踏实。很多团队在开发中后期遇到的慢 SQL、死锁、索引失效问题，用 MyBatis 都能快速从日志里定位并重写 SQL，这种自由度带来的维护优势，随着系统演进会越来越突出。希望这篇从入门到原理再到坑点总结的内容，对你理解 MyBatis 能有一个扎实的支撑，也欢迎按自己的项目情况做进一步实践验证。