Mybatis 持久层框架

动态 SQL 与缓存机制

MyBatis 的一级缓存和二级缓存有什么区别？

很多同学在使用 MyBatis 时能感受到“同一个查询好像不会重复查库”，但细说不清。我们一次性搞明白。

🔎 先看两张缓存的作用域

查看内嵌表格

🧠 一级缓存深入

在同一个 SqlSession 里，执行 select 时，MyBatis 会先查 LocalCache（一个 PerpetualCache，底层是 HashMap）。如果命中，直接返回，不再查库。 重要特性：

• 在执行 update、delete、insert 提交后，或者执行 SqlSession.clearCache() 后，缓存会被清空。

• 如果多个 SqlSession 同时操作同一数据，一级缓存会导致读到旧数据（因为另一个会话修改了数据库，本会话缓存未更新）。所以在并发环境下，不能依赖一级缓存来保证数据一致性。

🗄️ 二级缓存机制与配置

二级缓存是跨会话的。当某个 SqlSession 提交时，会将当前 select 的结果存入二级缓存区域；下一个新的 SqlSession 在相同 namespace 下执行相同查询时，就能从二级缓存直接取。

开启方式：

<!-- mybatis-config.xml -->
<settings>
    <setting name="cacheEnabled" value="true"/>
</settings>

<!-- 在 Mapper.xml 中添加 -->
<cache eviction="LRU" flushInterval="60000" size="512" readOnly="true"/>

或者在接口上标注：

@CacheNamespace(eviction = LruCache.class, flushInterval = 60000, size = 512, readOnly = true)
public interface UserMapper {
    @Select("SELECT * FROM users WHERE id = #{id}")
    User getUser(int id);
}

常见配置属性：

• eviction：回收策略 LRU/FIFO/SOFT/WEAK。

• flushInterval：刷新间隔（毫秒），到时间自动清空。

• size：缓存对象数量上限。

• readOnly：只读时性能更好，因为对象本身可被共享；读写时需要序列化拷贝。

二级缓存的查询流程：二级缓存 → 一级缓存 → 数据库。如果二级缓存命中，直接返回，不走一级缓存。

⚠️ 避坑指南

1. 不要在分布式环境直接用内置缓存：默认二级缓存基于本地内存，多实例间数据不一致。务必换成 Redis、Hazelcast 等分布式缓存实现（如 mybatis-redis 适配）。

2. 只有单表查询的 Mapper 才适合开二级缓存：如果 Mapper 中涉及复杂关联查询，可能由于一条关联更新导致该 namespace 整个缓存刷新，得不偿失。

3. 一级缓存的“坑”：在 Spring 集成时，每次查询默认用新的 SqlSession（通过 SqlSessionTemplate），所以一级缓存基本失效（每次查询都是新会话）。这就是为什么你在 Service 层调用两次 mapper.getUser(1)，会执行两次 SQL 的原因——Spring 中的一级缓存几乎是不起作用的。

📌 一句话总结：一级缓存是“单次会话的临时便签”，二级缓存是“跨会话的全局布告栏”。选型时，根据是否跨会话、是否分布式、数据一致性要求来抉择，别为了“缓存”而缓存。

---

MyBatis 的插件（Interceptor）机制是如何实现的？

MyBatis 插件让你可以插手 SQL 执行的各个环节，比如分页、慢 SQL 监控、数据脱敏。它的核心是责任链模式 + 动态代理，我们手动拆开看看。

⚙️ 工作原理四步走

1. 可拦截的四大对象：MyBatis 允许拦截 Executor（执行器）、ParameterHandler（参数处理）、ResultSetHandler（结果集处理）、StatementHandler（SQL 语句处理）。

2. 插件签名声明：每个插件必须用 @Intercepts + @Signature 声明要拦截哪个类的哪个方法，以及参数类型。

3. 生成代理对象：MyBatis 在创建这四大核心对象时，会调用 InterceptorChain.pluginAll(target)，内部遍历所有插件，对目标对象应用 Plugin.wrap()，最终返回一个层层包裹的 JDK 动态代理。

4. 执行链路：调用目标方法时，会先进入插件代理的 invoke 方法，在里面可以修改参数、执行额外逻辑，最后调用真实对象的方法。

🔨 写一个记录慢 SQL 的插件

@Intercepts({
    @Signature(
        type = StatementHandler.class,
        method = "prepare",
        args = {Connection.class, Integer.class}
    )
})
public class SlowSqlInterceptor implements Interceptor {

    // 慢查询阈值，单位毫秒
    private long threshold;

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        // 获取 StatementHandler，拿到绑定的 SQL
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        String sql = handler.getBoundSql().getSql();

        long start = System.currentTimeMillis();
        Object result = invocation.proceed();   // 执行原始方法
        long time = System.currentTimeMillis() - start;

        if (time > threshold) {
            System.err.println("慢查询 [" + time + "ms]: " + sql);
        }
        return result;
    }

    // 可以在配置时设置阈值
    @Override
    public void setProperties(Properties properties) {
        this.threshold = Long.parseLong(properties.getProperty("threshold", "1000"));
    }
}

注册到 MyBatis：

<plugins>
    <plugin interceptor="com.example.SlowSqlInterceptor">
        <property name="threshold" value="500"/>
    </plugin>
</plugins>

🧪 责任链如何串联

来看 Plugin 的核心代理逻辑：

// 简化版 Plugin.invoke
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    // 如果当前调用的方法匹配我们声明要拦截的方法，就交给插件的 intercept 方法
    if (methods.contains(method)) {
        return interceptor.intercept(new Invocation(target, method, args));
    }
    // 否则直接走原始对象的方法
    return method.invoke(target, args);
}

如果有多个插件，依次包裹：PluginA 代理 PluginB 代理 PluginC 代理 原始对象。调用时顺序为 A.intercept → B.intercept → C.intercept → 真实方法。这就是典型的责任链。

💡 实用场景扩展

• 分页插件（如 PageHelper）就是拦截 Executor.query，判断参数中是否需要分页，修改 SQL 并重新设置参数。

• 读写分离插件：拦截 Executor.update/query 方法，根据方法类型选择不同的数据源。

• 数据加密插件：拦截 ParameterHandler.setParameters，对敏感字段值加密；拦截 ResultSetHandler.handleResultSets 对字段值解密。

🔧 进阶提醒：插件中如果修改了 BoundSql 的 SQL 和参数，务必保持参数和占位符一致。而且 Interceptor 的实现需要考虑线程安全，因为核心对象可能被多线程共享。

理解了责任链模式，你也能写出优雅的横向切面，让 SQL 执行变成一块可以任意编排的积木。

---

Agent 需要根据运行时条件动态拼接查询 SQL，MyBatis 如何安全实现？

Agent 类应用（比如 ChatBI、智能查询助手）经常要根据用户的自然语言生成不同的查询条件，比如： “查一下上个月消费超过 1000 的VIP用户” → 动态生成 WHERE 条件。 MyBatis 提供了多种动态 SQL 方案，但安全第一，必须防注入。

🛡️ 安全前提：绝对不用 ${} 拼接用户输入

MyBatis 中 #{} 会使用预编译参数，安全；${} 是直接字符串替换，等于给 SQL 注入大开后门。动态拼接时，若必须拼接表名、列名这种无法预编译的部分，要做严格白名单校验。

📝 方案一：XML 动态标签（最安全、推荐）

利用 <if>, <where>, <foreach> 等标签，把运行时条件映射为参数。

示例：根据多个可选条件查询用户

<select id="queryUsers" resultType="User">
    SELECT * FROM users
    <where>
        <if test="name != null and name != ''">
            AND name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="minAmount != null">
            AND total_amount >= #{minAmount}
        </if>
        <if test="vip != null and vip == true">
            AND is_vip = 1
        </if>
    </where>
    <if test="orderBy != null">
        ORDER BY ${orderBy}   <!-- 这里必须白名单校验 -->
    </if>
</select>

对应的 Mapper 接口：

List<User> queryUsers(@Param("name") String name,
                      @Param("minAmount") BigDecimal minAmount,
                      @Param("vip") Boolean vip,
                      @Param("orderBy") String orderBy);

对于 orderBy 这种必须用 ${} 的地方，要在服务层做白名单过滤：

private static final Set<String> ALLOWED_COLUMNS = Set.of("id", "name", "create_time", "total_amount");

public List<User> safeQuery(String name, BigDecimal minAmount, Boolean vip, String orderBy) {
    if (orderBy != null && !ALLOWED_COLUMNS.contains(orderBy)) {
        throw new IllegalArgumentException("Invalid column: " + orderBy);
    }
    return mapper.queryUsers(name, minAmount, vip, orderBy);
}

📝 方案二：使用 SQL 构建器（Java API 动态拼接）

当条件太多、组合复杂，XML 会变得臃肿，这时可以用 MyBatis 自带的 SQL 类（org.apache.ibatis.jdbc.SQL）或以 SelectProvider 的方式在 Java 代码中构建。

动态构建的 Provider 类：

public class UserSqlProvider {
    public String buildQuery(Map<String, Object> params) {
        String name = (String) params.get("name");
        BigDecimal minAmount = (BigDecimal) params.get("minAmount");
        Boolean vip = (Boolean) params.get("vip");

        return new SQL() {{
            SELECT("*");
            FROM("users");
            if (name != null && !name.isEmpty()) {
                WHERE("name LIKE CONCAT('%', #{name}, '%')");
            }
            if (minAmount != null) {
                WHERE("total_amount >= #{minAmount}");
            }
            if (vip != null && vip) {
                WHERE("is_vip = 1");
            }
            // 排序字段必须从白名单取值后再拼
        }}.toString();
    }
}

Mapper 接口：

@SelectProvider(type = UserSqlProvider.class, method = "buildQuery")
List<User> queryUsersDynamic(Map<String, Object> params);

⚡ 方案三：Agent 复杂场景——基于元数据的查询引擎

如果你的 Agent 允许用户任意组合字段、操作符（>、<、=、IN等），就需要一套查询模板 + 元数据校验的机制。

简单设计思路：

1. 前端/Agent 生成一个结构化的查询描述对象，如：

{
  "conditions": [
    { "field": "total_amount", "op": "GE", "value": 1000 },
    { "field": "is_vip", "op": "EQ", "value": true }
  ],
  "orderBy": "create_time",
  "orderDir": "DESC"
}

1. 后端定义一个字段元数据表（或枚举），记录每个允许查询的字段名、数据类型、是否支持排序。

2. 服务层遍历 conditions，通过白名单验证 field 合法，根据类型参数化拼接 SQL。绝不能直接把用户的字段名插入 SQL，必须从元数据中映射后才可拼接。

伪代码示例：

@SelectProvider(type = AgentQueryProvider.class, method = "buildDynamicQuery")
List<Map<String, Object>> executeQuery(QueryRequest request);

// 在 Provider 内部使用 StringBuilder + 参数化构建，所有值用 #{paramX}

MyBatis 提供的 #{param} 将始终使用 PreparedStatement，所以只要不把用户值拼到 SQL 字符串中，基本没有注入风险。

🔐 安全铁律

• 值：一律 #{xxx}。

• 列名、表名、操作符：白名单映射，不用 #{} 而用常量替换。

• IN 查询：<foreach> 配合 #{item}，安全。

• 排序、分页：对参数做枚举校验。

💡 把“安全”刻在每次拼接的肌肉记忆里，你交付的 Agent 才不会是定时炸弹。动态 SQL 的能力越强，安全防护就要越硬。

MyBatis 的 Mapper 接口没有实现类，为什么能直接调用？底层原理是什么？

这个问题是 MyBatis 的灵魂拷问，理解了它，框架在你面前基本就是透明的了。

🔍 一句话原理

MyBatis 在运行时通过 JDK 动态代理 为 Mapper 接口生成了一个代理对象。当你调用接口方法时，真正干活的是 MapperProxy，它把方法调用翻译成对应的 SQL 执行。

🧩 拆解：从接口到 SQL 的全过程

① 启动时：解析 XML / 注解，建立映射关系 MyBatis 启动时会解析每个 mapper.xml 或 Mapper 接口上的注解，把每个 SQL 语句封装成一个 MappedStatement 对象，并以 “接口全限定名 + 方法名” 作为唯一标识（namespace.id）存入全局 Configuration 中。

② 获取 Mapper 对象：SqlSession.getMapper() 当你调用 sqlSession.getMapper(UserMapper.class) 时，MyBatis 会调用 MapperRegistry 获取或创建一个代理实例。核心代码：

// 简化版 MapperProxyFactory
public T newInstance(SqlSession sqlSession) {
    final MapperProxy<T> mapperProxy = new MapperProxy<>(sqlSession, mapperInterface, methodCache);
    return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[]{mapperInterface}, mapperProxy);
}

③ 方法调用：被 MapperProxy.invoke() 拦截 每次调用 userMapper.getUser(1) 时，会被代理对象的 invoke 方法拦截。它会根据当前方法找到对应的 MappedStatement，然后判断方法返回类型和 SQL 类型（SELECT/INSERT/UPDATE/DELETE），最终委托给 SqlSession 执行。

④ 真正执行 SQL SqlSession 会通过 Executor 执行器，经过缓存、插件拦截等，最终通过 JDBC 的 PreparedStatement 执行 SQL，并把结果集转换为方法返回值类型（List、对象等）。

📊 流程图

UserMapper userMapper = sqlSession.getMapper(UserMapper.class)
                            |
                            v
                  MapperRegistry.getMapper()
                  -> Proxy.newProxyInstance()
                            |
                   返回动态代理对象 $Proxy
                            |
                 userMapper.getUser(1)
                            |
                   进入 MapperProxy.invoke()
                            |
                 获取 MappedStatement (statementId = "com.xxx.UserMapper.getUser")
                            |
                判断 SQL 命令类型 (SELECT) 与返回值类型
                            |
            调用 sqlSession.selectOne(statementId, param)
                            |
                     Executor 处理缓存、插件 -> StatementHandler -> JDBC
                            |
                   返回结果集 -> 映射为 User 对象

🧪 验证：自己写一个“迷你版 MapperProxy”

public class MiniMapperProxy implements InvocationHandler {
    private SqlSession sqlSession;

    public MiniMapperProxy(SqlSession sqlSession) {
        this.sqlSession = sqlSession;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // 假设约定接口方法名就是 statement id
        String statement = method.getDeclaringClass().getName() + "." + method.getName();
        // 判断返回值类型决定调用 selectOne 还是 selectList
        if (method.getReturnType().isAssignableFrom(List.class)) {
            return sqlSession.selectList(statement, args[0]);
        } else {
            return sqlSession.selectOne(statement, args[0]);
        }
    }
}

// 手动创建代理
UserMapper mapper = (UserMapper) Proxy.newProxyInstance(
        UserMapper.class.getClassLoader(),
        new Class[]{UserMapper.class},
        new MiniMapperProxy(sqlSession));

这就是 MyBatis “零实现类” 的魔法本质。你写的每一个接口方法，最终都被翻译成了 sqlSession 上的操作。

🧠 思考延伸

• 既然接口没有实现类，那接口里的 default 方法可以直接运行，因为代理无法拦截 default 方法，执行的是接口本身的字节码。

• MyBatis-Plus 的 BaseMapper 就是在 Mapper 接口上增加了一层抽象，内部依旧是这套动态代理机制。

• 理解了这一套，以后遇到“MyBatis 方法重载”相关问题（不推荐重载，因为 statement id 只认方法名）就豁然开朗了。

📌 这一题，你如果能从动态代理讲到 MappedStatement 映射，再到 SqlSession 的执行，面试官就知道你不是只会用，而是吃透了。

---

Agent 的对话记录需要存储到 MySQL，消息体是变长 JSON，如何用 MyBatis 优雅处理？

Agent 的对话历史通常是一条记录里包含一个变长、嵌套的 JSON 消息数组（如对话轮次、tool_calls、参数等）。MySQL 从 5.7 开始原生支持 JSON 类型，但 MyBatis 如何优雅地把它映射到 Java 对象并写入/读取？

🗄️ 场景示例：消息表结构

CREATE TABLE agent_conversation (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    session_id VARCHAR(64) NOT NULL,
    messages JSON NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

messages 字段存储类似：

[
  {"role": "user", "content": "帮我查一下订单"},
  {"role": "assistant", "content": "好的，订单号是？", "tool_calls": null}
]

对应的 Java 模型：

public class Conversation {
    private Long id;
    private String sessionId;
    private List<Message> messages;  // 映射到 JSON 列
    private LocalDateTime createdAt;
}
public class Message {
    private String role;
    private String content;
    private Object toolCalls; // 可进一步定义结构
}

✨ 优雅处理方案：自定义 TypeHandler

MyBatis 默认不认识 List<Message> 到 JSON 的转换。我们需要写一个 TypeHandler，利用 Jackson 做序列化/反序列化。

定义 TypeHandler

@MappedTypes(List.class)   // 可指定为 List<Message> 但泛型擦除，需注意
@MappedJdbcTypes(JdbcType.VARCHAR)  // MySQL JSON 类型在 JDBC 中映射为 VARCHAR 或 LONGVARCHAR
public class MessageListTypeHandler extends BaseTypeHandler<List<Message>> {

    private static final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public void setNonNullParameter(PreparedStatement ps, int i,
                                    List<Message> parameter, JdbcType jdbcType)
                                    throws SQLException {
        try {
            ps.setString(i, objectMapper.writeValueAsString(parameter));
        } catch (JsonProcessingException e) {
            throw new SQLException("Failed to convert messages to JSON", e);
        }
    }

    @Override
    public List<Message> getNullableResult(ResultSet rs, String columnName)
                                           throws SQLException {
        String json = rs.getString(columnName);
        return parseJson(json);
    }

    @Override
    public List<Message> getNullableResult(ResultSet rs, int columnIndex)
                                           throws SQLException {
        String json = rs.getString(columnIndex);
        return parseJson(json);
    }

    @Override
    public List<Message> getNullableResult(CallableStatement cs, int columnIndex)
                                           throws SQLException {
        String json = cs.getString(columnIndex);
        return parseJson(json);
    }

    private List<Message> parseJson(String json) {
        if (json == null || json.isEmpty()) return Collections.emptyList();
        try {
            return objectMapper.readValue(json, new TypeReference<List<Message>>() {});
        } catch (JsonProcessingException e) {
            throw new RuntimeException("Failed to parse JSON to messages", e);
        }
    }
}

注册 TypeHandler 在 mybatis-config.xml 中：

<typeHandlers>
    <typeHandler handler="com.example.handler.MessageListTypeHandler"
                 javaType="java.util.List" jdbcType="VARCHAR"/>
</typeHandlers>

或者 MyBatis-Plus/Spring Boot 项目，可以在配置类中手动注册：

configuration.getTypeHandlerRegistry().register(List.class, JdbcType.VARCHAR, new MessageListTypeHandler());

更方便的是在 Mapper XML 中直接指定 typeHandler。

使用方式 在 Mapper XML 的 resultMap 或字段映射中引用：

<resultMap id="conversationMap" type="Conversation">
    <id property="id" column="id"/>
    <result property="sessionId" column="session_id"/>
    <result property="messages" column="messages"
            typeHandler="com.example.handler.MessageListTypeHandler"/>
    <result property="createdAt" column="created_at"/>
</resultMap>

或者更简洁的注解方式（MyBatis 3.5+ 支持注解指定 TypeHandler）：

@Results({
    @Result(property = "messages", column = "messages",
            typeHandler = MessageListTypeHandler.class)
})
@Select("SELECT * FROM agent_conversation WHERE session_id = #{sessionId}")
Conversation getBySessionId(String sessionId);

这样，你的 Java 代码中就可以直接读写强类型的 List<Message>，MyBatis 在中间完成透明的 JSON 转换。

🚀 进阶：利用 MySQL 的 JSON 函数查询

有时候我们需要对 JSON 内部字段进行查询，比如查询包含某个 tool_call 的会话。MyBatis 依然可以安全使用预编译：

<select id="findByToolName" resultMap="conversationMap">
    SELECT * FROM agent_conversation
    WHERE JSON_CONTAINS(messages, #{toolName}, '$.tool_calls[*].function.name')
</select>

参数用 #{toolName} 安全预编译。建议在业务层对这些函数做一层封装，避免 SQL 散落各处。

🧰 替代方案：把 JSON 当作字符串，Service 层手动转换

如果项目很简单，不想写 TypeHandler，也可以在 Entity 里把 messages 定义为 String，然后在 Service 层用 Jackson 手动转换。但这样破坏了持久层的对象语义，个人更推荐 TypeHandler 方案，它把转换逻辑收归到 MyBatis 类型系统内，代码更干净。

🔐 安全性补丁

• JSON 内容可能很大，注意 MySQL max_allowed_packet 大小限制。

• 反序列化时注意多态问题，如果你的 Message 有子类，需要配置 Jackson 的多态解析。

• TypeHandler 中使用的 ObjectMapper 应该共用同一个实例（static final），避免创建开销。

💡 总结

通过自定义 TypeHandler，我们把 MySQL 的 JSON 列映射为强类型的 Java 对象集合，让数据库层的半结构化数据在业务代码中以完全面向对象的形式出现。这是一个典型的“基础设施即工具”思路：花一点力气做好适配，上层就能享受到类型安全和编写便利。对于 Agent 这种消息结构灵活多变的场景，这一招能让你的持久层代码简洁又健壮。

---

一级缓存与二级缓存

1、MyBatis 的一级缓存和二级缓存有什么区别？

难度级别：⭐⭐（缓存级别、失效条件、脏读风险）

1️⃣ Common Answer 一级缓存是 SqlSession 级别的，默认开启，同一个 SqlSession 里查询相同数据会走缓存。二级缓存是 Mapper 级别的，需要配置开启，多个 SqlSession 可以共享缓存。一级缓存会在增删改操作后失效，二级缓存也是一样。

2️⃣ Impressive Answer

1. 一级缓存（SqlSession 级别）：基于 PerpetualCache 实现，默认开启，缓存 key 是 Statement ID + 参数 + SQL。在同一个 SqlSession 内，相同查询直接返回缓存结果，避免重复查询数据库。失效条件：执行 insert/update/delete、调用 sqlSession.clearCache()、SqlSession 关闭。

2. 二级缓存（Mapper 级别）：基于 Mapper 的 namespace，需要配置 <cache/> 开启，多个 SqlSession 共享同一 Mapper 的缓存。核心区别：一级缓存只在 SqlSession 内有效，二级缓存跨 SqlSession 共享；二级缓存需要序列化对象（要求实体类实现 Serializable）。

3. 多表查询脏读风险：一级缓存可能脏读（多表关联时，只查询主表可能返回缓存的旧数据），二级缓存通过 flushCache 配置避免。最佳实践：多表关联查询时关闭二级缓存或设置 flushCache="true"，避免脏数据。

4. Spring 整合后的行为：Spring 整合 MyBatis 后，SqlSession 由 Spring 管理，一级缓存在事务内有效，事务提交后 SqlSession 关闭，一级缓存清空。二级缓存独立于事务，适合读多写少的场景。

3️⃣ Key Differences

查看内嵌表格

---

2、MyBatis 一级缓存在 Spring 事务中的行为是什么？为什么开启事务后缓存命中率更高？

难度级别：⭐⭐⭐（事务管理、缓存共享、命中机制）

1️⃣ Common Answer Spring 事务中，SqlSession 是共享的，所以一级缓存在事务内有效。开启事务后，多次查询会走缓存，命中率更高。事务提交后 SqlSession 关闭，缓存清空。

2️⃣ Impressive Answer

1. Spring 整合后的 SqlSession 管理：Spring 使用 SqlSessionTemplate 代理 SqlSession，默认每次操作创建新 SqlSession。但在事务内，Spring 通过 SqlSessionHolder 绑定当前 SqlSession 到 ThreadLocal，整个事务共享同一个 SqlSession，一级缓存生效。

2. 缓存命中率提升的原因：无事务时，每次数据库操作都创建新 SqlSession，一级缓存无法跨操作共享；开启事务后，同一事务内的多次查询共享 SqlSession，相同查询直接命中一级缓存，避免重复查库。性能提升：高频查询场景（如 Agent 对话记录查询），事务内缓存命中率可达 90%+。

3. 事务提交后的缓存清理：事务提交时，Spring 会调用 SqlSessionUtils.closeSqlSession() 清理 SqlSession，一级缓存自动清空，避免脏读。二级缓存独立于事务，事务提交后二级缓存仍然有效。

4. Agent 场景实践：Agent 查询对话记录时，在 @Transactional 方法内多次查询相同 Session，一级缓存生效，减少 DB 压力。但注意：事务内避免大对象查询（如加载全量历史消息），防止一级缓存占用过多内存。

3️⃣ Key Differences

查看内嵌表格

---

3、场景题：Agent 的知识库查询接口 QPS 很高，如何合理利用 MyBatis 缓存减少数据库压力？

难度级别：⭐⭐⭐（缓存策略、性能优化、Agent 场景）

1️⃣ Common Answer 开启 MyBatis 的二级缓存，知识库查询走缓存，减少数据库压力。设置缓存过期时间，避免数据过期。用 Redis 做缓存，提高性能。

2️⃣ Impressive Answer

1. 二级缓存配置：在知识库 Mapper XML 中配置 <cache eviction="LRU" flushInterval="60000" size="1024"/>，使用 LRU 淘汰策略，60 秒刷新，缓存 1024 个对象。注意：实体类实现 Serializable，二级缓存需要序列化。

2. 一级缓存 + 事务优化：在高频查询接口（如 Agent 知识库检索）使用 @Transactional(readOnly = true)，同一事务内多次查询共享一级缓存，避免重复查库。性能提升：单次请求内多次查询相同知识库条目，一级缓存命中率可达 100%。

3. 缓存失效策略：知识库更新时，调用 sqlSession.clearCache() 清空一级缓存；二级缓存通过 flushCache="true" 在 update/delete 时自动失效。Agent 场景：知识库更新频率低，二级缓存命中率高，QPS 1000+ 时 DB 压力可降低 80%。

4. 混合缓存方案：热点知识库条目（如 FAQ）用二级缓存，冷数据用 Redis 分布式缓存；大对象（如向量数据）不缓存，避免内存溢出。监控指标：缓存命中率、缓存大小、DB QPS，通过 MyBatis 插件统计缓存效果。

3️⃣ Key Differences

查看内嵌表格

---

4、容易一起考的题

查看内嵌表格

---

SQL 执行全链路

1、基础题：MyBatis 中 SqlSession 的作用是什么？它和 SqlSessionFactory 的关系？

难度级别：⭐⭐（SqlSession 作用、工厂模式、生命周期）

1️⃣ Common Answer SqlSession 是 MyBatis 的核心接口，用于执行 SQL、获取 Mapper、管理事务。SqlSessionFactory 是工厂，用来创建 SqlSession。SqlSessionFactory 是单例的，SqlSession 每次用完要关闭。

2️⃣ Impressive Answer

1. SqlSession 的作用：SqlSession 相当于 JDBC 的 Connection，封装了 Executor、StatementHandler、Transaction 等组件，提供 selectList()、insert()、update()、delete() 等方法执行 SQL，以及 getMapper() 获取 Mapper 代理对象，commit()/rollback() 管理事务。

2. SqlSessionFactory 的职责：SqlSessionFactory 是重量级对象，创建时加载配置文件（mybatis-config.xml）、Mapper XML，构建 Configuration 对象，内部维护 Executor、StatementHandler 等组件的工厂方法。生命周期：应用级别，全局单例，线程安全。

3. 关系与生命周期：SqlSessionFactory 创建 SqlSession，SqlSession 是轻量级对象，非线程安全，每次请求创建新实例，用完必须关闭（finally 块中调用 close()）。Spring 整合：Spring 管理 SqlSessionFactory（单例），SqlSession 由 SqlSessionTemplate 代理，自动管理生命周期。

4. 底层实现：SqlSession 默认实现是 DefaultSqlSession，内部持有 Configuration、Executor、Transaction；SqlSessionFactory 默认实现是 DefaultSqlSessionFactory，通过 openSession() 创建 SqlSession，可指定 Executor 类型（SIMPLE、REUSE、BATCH）。

3️⃣ Key Differences

查看内嵌表格

---

2、进阶题：MyBatis 的 SQL 执行流程是什么？从 sqlSession.selectList() 到 JDBC 的完整链路？

难度级别：⭐⭐⭐（执行链路、组件协作、JDBC 封装）

1️⃣ Common Answer SqlSession 调用 selectList，然后 Executor 执行 SQL，StatementHandler 处理 JDBC，最后返回结果。中间还有 ParameterHandler 和 ResultSetHandler 处理参数和结果。

2️⃣ Impressive Answer

1. SqlSession.selectList()：调用 Configuration.getMappedStatement() 获取 MappedStatement（包含 SQL、参数映射、结果映射），然后调用 executor.query()。

2. Executor.query()：BaseExecutor 先查一级缓存（localCache），命中直接返回；未命中则调用 doQuery()。二级缓存：CachingExecutor 先查二级缓存，未命中再查一级缓存，最后查数据库。

3. StatementHandler.prepare()：创建 JDBC Statement（PreparedStatement），调用 ParameterHandler.setParameters() 设置参数（处理 #{} 占位符），然后 StatementHandler.query() 执行 SQL。

4. ResultSetHandler.handleResultSets()：处理 JDBC ResultSet，根据 ResultMap 映射结果对象，支持嵌套结果、延迟加载。返回结果：List