乐于分享
好东西不私藏

面试官:说说 MyBatis 插件和缓存原理?从机制到实战,全给你讲透

面试官:说说 MyBatis 插件和缓存原理?从机制到实战,全给你讲透

一、MyBatis 插件机制:拦截器是怎么工作的

MyBatis 允许你在 SQL 执行的四个关键时刻插入自定义逻辑,这就是插件机制(Interceptor)。

四个可拦截的对象:

1. Executor(执行器)——增删改查的顶层入口,拦截它可以做读写分离、分库分表

2. ParameterHandler(参数处理器)——给 SQL 设置参数,拦截它可以加解密参数、替换敏感字段

3. ResultSetHandler(结果集处理器)——把查询结果转成 Java 对象,拦截它可以脱敏返回值、自动填充字段

4. StatementHandler(语句处理器)——负责创建 Statement、管理预编译,拦截它可以改写 SQL、加执行计划分析

实现一个插件的步骤很简单:

1. 实现 Interceptor 接口

2. 用 @Intercepts 和 @Signature 注解声明要拦截哪个对象的哪个方法

3. 在 mybatis-config.xml 或 Spring 配置里注册

@Intercepts({    @Signature(        type = Executor.class,        method = "update",        args = {MappedStatement.class, Object.class}    )})public class SqlLogInterceptor implements Interceptor {    @Override    public Object intercept(Invocation invocation) throws Throwable {        MappedStatement ms = (MappedStatement) invocation.getArgs()[0];        System.out.println("执行 SQL: " + ms.getSqlSource().getBoundSql(invocation.getArgs()[1]).getSql());        long start = System.currentTimeMillis();        Object result = invocation.proceed();        System.out.println("耗时: " + (System.currentTimeMillis() - start) + "ms");        return result;    }    @Override    public Object plugin(Object target) {        return Plugin.wrap(target, this);    }}

Spring Boot 项目里注册:

@Configurationpublic class MyBatisConfig {    @Bean    public SqlLogInterceptor sqlLogInterceptor() {        return new SqlLogInterceptor();    }}

底层原理:MyBatis 用 JDK 动态代理生成目标对象的代理类。intercept() 方法里通过 invocation.proceed() 调用原始方法,你在它前后加逻辑就完成了 AOP。

常用的插件场景:

- SQL 日志打印 + 慢 SQL 告警

- 字段加密/解密(拦截 ParameterHandler 和 ResultSetHandler)

- 分页(拦截 Executor,改写 SQL 加 limit)

- 数据权限过滤(拦截 StatementHandler,改写 WHERE 条件加租户 ID)

- 读写分离(拦截 Executor,select 走从库,其他走主库)

二、MyBatis 缓存机制:一级缓存与二级缓存

MyBatis 内置了两层缓存,目的是减少数据库查询次数。

一级缓存(SqlSession 级别)

一级缓存是默认开启的,作用范围是同一个 SqlSession。你在同一个 SqlSession 里执行两次相同的查询,第二次会直接从缓存拿结果,不查数据库。

一级缓存的本质是 PerpetualCache 对象,内部就是一个 HashMap,key 是 SQL + 参数 + 语句 ID + 分页信息拼接出来的 CacheKey。

// 同一 SqlSession,同一个查询,第一次查库第二次走缓存try (SqlSession session = sqlSessionFactory.openSession()) {    UserMapper mapper = session.getMapper(UserMapper.class);    User u1 = mapper.findById(1L);  // 查数据库    User u2 = mapper.findById(1L);  // 走一级缓存    System.out.println(u1 == u2);   // true(同一个对象引用)}

一级缓存什么时候失效:

1. 执行了 insert/update/delete(无论操作哪张表,整个 SqlSession 的缓存全部清空)

2. 调用了 SqlSession.clearCache()

3. SqlSession 关闭

4. 查询条件不同(CacheKey 不同)

坑点:在 Spring 管理的事务中,一个事务方法内共享同一个 SqlSession,所以一级缓存默认生效。但如果调用的是不同 Mapper 方法,且中间没有 DML 操作,同一个查询确实走缓存。但要注意 —— 跨方法调用时,如果 Spring AOP 切面重新获取了 SqlSession,一级缓存就丢了。所以一级缓存通常只在一个方法内可靠。

二级缓存(Mapper 级别 / namespace 级别)

二级缓存是跨 SqlSession 的,同一个 Mapper(同一个 namespace)下的查询结果可以被多个 SqlSession 共享。默认关闭,需要手动开启。

开启步骤:

1. mybatis-config.xml 设置 <setting name="cacheEnabled" value="true"/>(默认就是 true)

2. Mapper XML 里加 <cache/> 标签

3. 查询结果对应的 POJO 要实现 Serializable 接口

// mybatis-config.xml(可不配,默认 true)<setting name="cacheEnabled" value="true" />// UserMapper.xml — 开启二级缓存<mapper namespace="com.example.mapper.UserMapper">    <cache        eviction="LRU"          // 淘汰策略        flushInterval="60000"   // 刷新间隔(毫秒)        size="512"              // 缓存对象数量        readOnly="true" />      // 只读(性能更好)    <select id="findById" ... useCache="true">...</select></mapper>

二级缓存的工作原理:

1. 查询时,先查二级缓存(namespace 级别)→ 没有再查一级缓存(SqlSession 级别)→ 没有再查数据库

2. 二级缓存的数据是序列化存储的,所以取出来是不同对象(和一级缓存存对象引用不同)

3. 同一个 namespace 下的 insert/update/delete 会清空该 namespace 的二级缓存

二级缓存的大坑

二级缓存最大的问题是跨 namespace 的数据一致性问题。如果两个 Mapper 操作同一张表,缓存不会自动同步。

// UserMapper 查询用户// OrderMapper 也查了用户关联的 user 表// UserMapper 的缓存没清,OrderMapper 改了数据用户看不到更新// 解决方案:用 <cache-ref namespace="UserMapper" />// 让 OrderMapper 的缓存引用 UserMapper 的缓存

实际生产环境中,大多数团队选择关闭二级缓存,因为:

1. 缓存同步问题难解决,多表联查时 namespace 的粒度太粗

2. 分布式部署下,二级缓存只在单机内有效,需要另外集成 Redis

3. 一级缓存 + Redis 第三方缓存的组合更可控

三、扩展点与缓存的联动

插件机制和缓存不是孤立的。如果你实现了一个自定义 Executor 插件(比如分页插件),它会直接影响到缓存的行为——因为缓存挂载在 Executor 上。Executor 的 query() 方法调用前会先检查缓存,插件如果拦截了 Executor.query(),需要在方法内正确地调用 invocation.proceed() 才能触发缓存逻辑。

另一个常见场景:用插件做数据权限时,会在 SQL 的 WHERE 条件后面自动追加租户 ID。如果你的 Mapper 开启了二级缓存,不同租户的查询可能因为 CacheKey 不同而正确隔离(因为追加了不同参数)。但如果 CacheKey 的计算没有包含权限参数,就会出现数据串问题。

// 插件改写 SQL 时要保证 CacheKey 也变化// 自定义 CacheKey 添加租户 IDpublic class TenantCacheKey extends CacheKey {    public TenantCacheKey(String sql, Object params, String tenantId) {        super(sql, params);        this.update(tenantId);  // 租户 ID 加入 hash 计算    }}

常见面试题与参考答案

1. MyBatis 的一级缓存和二级缓存有什么区别?

参考答案:一级缓存是 SqlSession 级别,默认开启,缓存对象引用(同一对象),生命周期是 SqlSession 的生命周期。二级缓存是 Mapper namespace 级别,需要手动开启,缓存序列化后的对象副本,跨 SqlSession 共享。一级缓存在执行 DML 或 clearCache 时失效;二级缓存在同 namespace 的 DML 操作时失效。生产环境中二级缓存使用较少,因为跨 namespace 的一致性问题难以控制。

2. 如何实现一个 MyBatis 拦截器来做字段加密?

参考答案:需要拦截两个对象——ParameterHandler 的 setParameters 方法(写入时加密参数)和 ResultSetHandler 的 handleResultSets 方法(读取时解密结果)。通过 @Intercepts 注解声明两个 @Signature,在 intercept 方法内根据字段注解判断是否加密/解密。注意:加密后不能影响模糊查询,通常用 AES 加密且确保结果是 Base64 编码的字符串。

3. MyBatis 分页插件原理是什么?

参考答案:分页插件拦截的是 Executor 的 query 方法,在 invocation.proceed() 之前改写 SQL:先执行 count 查询获取总条数,再对原 SQL 追加 limit 语句获取当前页数据。关键在于 BoundSql 的构造——需要把分页参数(page、limit)注册到 ParameterMapping 中,这样 SET 语句才能正确绑定参数值。插件通过 Dialect 接口抽象不同数据库的语法(MySQL 用 limit,Oracle 用 rownum),实现数据库无关的分页。