MyBatis 原理面试别只说 “写 XML 操作数据库”！三层深度拆解 + 缓存设计，直击大厂考点

前言

很多人面试被问 MyBatis 工作原理，张口就来 “ORM 框架，写 XML 操作数据库”，这种回答最多算及格，远达不到大厂的要求。面试官真正想听的，不是你会不会用配置，而是你有没有理解框架的设计思想 —— 为什么互联网公司清一色用 MyBatis，而不用 Hibernate？核心就两个字：控制权。

当你能把一个接口从 3 秒优化到 300 毫秒时，你就会明白这种对 SQL 的精准控制权有多重要。这篇文章就从动态代理层、核心执行层、设计思想层三层深度拆解 MyBatis 原理，再把一级二级缓存的设计、坑点、大厂最佳实践讲透，最后给你一套可直接套用的面试高分回答模板。

第一层：Mapper 接口为什么没有实现类？—— 动态代理机制

我们只写 Mapper 接口，不用写实现类，调用方法就能执行 SQL，底层的核心就是JDK 动态代理。

1.1 代理生成逻辑

MyBatis 在启动时，会为每个 Mapper 接口生成一个动态代理对象MapperProxy。你调用接口方法时，实际调用的是代理对象的invoke()方法，它会根据方法签名去全局配置Configuration里，找到对应的MappedStatement。

1.2 关键概念：MappedStatement

每条 SQL 在 MyBatis 启动时，都会被解析封装成一个MappedStatement对象，里面包含：

• SQL 模板
• 参数映射规则
• 结果映射规则
• 缓存配置

所有和这条 SQL 相关的信息全部预加载完成，不是每次执行都解析 XML，这就是为什么 MyBatis 启动相对慢，但运行时速度快的原因。

1.3 极简代码示例

// 你只需要写接口
public interface UserMapper {
User selectById(Long id);
}

// 底层自动生成代理对象
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
// 调用方法实际走的是代理的invoke方法
User user = mapper.selectById(1L);

第二层：核心执行机制 —— 一次查询完整五步流程

调用 Mapper 方法时，内部完整的执行流程可以拆解为五步：

2.1 Executor 执行器体系

执行器是 MyBatis 的核心调度组件，一共三种基础执行器 + 一种缓存装饰器，性能差异非常大：

核心设计巧思：缓存不是夹在业务代码层，而是夹在执行器层。CachingExecutor 只负责缓存的查询和写入，真正的数据库查询还是交给内部的基础执行器去做，职责分离非常清晰。

第三层：设计思想 —— 半自动 ORM 的本质是控制权

这才是面试官真正想听的深度，也是 MyBatis 能碾压 Hibernate 成为互联网标配的根本原因。

3.1 全自动 ORM 的痛点

往前十年，大家都在用 Hibernate 这种全自动 ORM 框架，自动生成 SQL，听起来很省心，但真实业务里 80% 的性能问题都出在 SQL 上：

• 表关联复杂时，框架自动生成的 SQL 可能关联 5 张表，走全表扫描十万行数据，3 秒才能返回
• 想优化 SQL、加索引提示、调整连接顺序，都非常困难，最后往往得跳出 ORM 写原生 SQL，反而失去了便利性

3.2 MyBatis 的设计哲学

MyBatis 走的是半自动 ORM路线：它不帮你生成 SQL，只负责把你写的 SQL 和 Java 代码连接起来。 你想怎么写 SQL 就怎么写，想加索引提示就加，想怎么优化就怎么优化，这种对 SQL 的精准控制权，才是性能优化的根本。

真实案例：一个订单查询接口，复杂关联下 Hibernate 自动生成的 SQL 要 3 秒返回；手写优化 SQL，只关联两张表，用inner join配合索引扫描一百行，300 毫秒就能返回。十倍的性能差距，就是 SQL 控制权的价值。

深度拓展：两级缓存设计与权衡

MyBatis 的缓存设计，最能体现框架的成熟度 —— 它不替你做决定，而是把选择权交给你：要性能还是要强一致性，自己选。

4.1 一级缓存（SqlSession 级）

• 作用域：同一个 SqlSession 内，默认开启
• 生命周期：和事务基本一致，正常情况下不会出现跨事务脏读
• 底层原理：本地内存缓存，key 由 statementId、SQL、参数共同组成
• 经典坑点：同一个 SqlSession 里，如果数据被外部程序修改，而没触发 MyBatis 的更新操作，就会读到旧数据。Spring 事务中 SqlSession 会被复用，分布式场景下更容易踩坑。
• 大厂最佳实践：设置localCacheScope=STATEMENT，让一级缓存只在单条语句内生效，从根源上规避事务级缓存带来的脏读风险。

4.2 二级缓存（Mapper 级）

• 作用域：跨 SqlSession 共享，同一个 Mapper namespace 下共用，需要手动开启
• 设计特点：插件化设计，默认只有内存实现，可以自定义实现
• 一致性问题：分布式场景下，一个节点更新了数据库，其他节点还挂着旧缓存，就会读到脏数据
• 大厂最佳实践：不使用默认的内存二级缓存，而是实现 MyBatis 的Cache接口，把缓存放到 Redis；或者直接在业务层做缓存，既能享受性能提升，又能解决分布式一致性问题。

面试高分回答模板

面试官问 “MyBatis 工作原理是什么”，按这个逻辑答，直接和普通候选人拉开差距：

我会从设计目标、核心机制、设计权衡三个层面来说： 第一，设计目标：MyBatis 是半自动 ORM 框架，核心设计是 SQL 和 Java 代码分离，保留开发者对 SQL 的绝对控制权，方便复杂场景下的性能优化。 第二，核心机制：

• 接口层通过 JDK 动态代理为 Mapper 接口生成代理对象，启动时解析所有 SQL 封装成 MappedStatement 预加载
• 执行层通过 SqlSession 调度 Executor，经过参数解析、SQL 绑定、执行、结果映射五步完成查询
• 缓存采用装饰器模式实现两级缓存，一级缓存是 SqlSession 级，二级缓存是 Mapper 级 第三，设计权衡：
• 不做全自动 SQL 生成，是为了保留 SQL 控制权，方便复杂查询的性能优化
• 分两级缓存，是为了权衡性能和数据一致性，开发者可以根据场景选择
• 实际生产中，大厂通常会把一级缓存设为语句级规避脏读，二级缓存用 Redis 替代，解决分布式一致性问题

这样回答，面试官一听就知道你是真懂，而不是只会背配置。

思维发散：延伸与进阶

5.1 常见坑点排查

• 一级缓存脏读：分布式、多事务场景下，优先调整localCacheScope
• 二级缓存失效：增删改操作会清空对应 namespace 的二级缓存，频繁写的场景不适合开启
• 分页插件与缓存冲突：分页插件会改写 SQL，可能导致缓存 key 不匹配

5.2 性能优化方向

• 高频查询场景启用ReuseExecutor，复用 Statement 减少预编译开销
• 批量操作使用BatchExecutor，大幅提升写入性能
• 读多写少场景合理使用缓存，写多读少场景直接关闭二级缓存
• 针对慢 SQL，直接在 XML 里优化 SQL 语句，这正是 MyBatis 的核心优势

5.3 主流 ORM 框架横向对比