MyBatis 延迟加载与一二级缓存核心知识点
一、延迟加载（Lazy Loading）
1. 核心定义
延迟加载是 MyBatis 对关联查询的优化机制：查询主对象时，不立即查询其关联对象（如用户和账户的一对多关系），仅在实际使用关联对象（调用 getter 方法）时，才触发关联查询的 SQL 执行。
2. 核心对比（延迟加载 vs 立即加载）
| 加载方式 | 执行时机 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 延迟加载 | 调用关联对象 getter 时 | 关联数据不常使用、关联表数据量大 | 减少无效查询，提升性能 | 可能触发 N+1 问题（循环查询时） |
| 立即加载 | 查询主对象时（如 LEFT JOIN 关联） | 关联数据必用、数据量小 | 一次查询完成，避免多次数据库交互 | 冗余数据加载，性能损耗 |
3. 实现原理
基于 动态代理：查询主对象时，MyBatis 返回主对象的代理实例；当调用关联对象的 getter 方法时，代理对象拦截该调用，触发关联查询 SQL 执行，查询结果赋值后返回。
4. 配置要求（全局开启）
需在 SqlMapConfig.xml 的 <settings> 标签中配置（MyBatis 默认为关闭）：
xml
5. 关联查询配置（XML 示例）
一对多（用户 -> 账户）
xml
ofType="cn.tx.domain.Account"
column="id"
select="cn.tx.mapper.AccountMapper.findAccountsByUid"/>
一对一（用户 -> 身份证）
xml
column="id"
select="cn.tx.mapper.IdCardMapper.findByIdCardByUid"/>
6. 关键注意事项
- SqlSession 存活要求：延迟加载需通过
SqlSession执行关联查询，因此调用getter前，SqlSession不能关闭（否则报PersistenceException）。 - N+1 问题规避：循环查询多个主对象时，避免逐个触发关联查询（1 次主查询 + N 次关联查询）；大量数据建议用
LEFT JOIN立即加载。 - 实体类无特殊要求：无需实现接口，仅需保证关联属性有
getter/setter方法（代理对象需通过getter触发加载）。
二、MyBatis 缓存机制（一级缓存 + 二级缓存）
MyBatis 缓存的核心目的是减少数据库查询次数，提升性能，分为一级缓存（本地缓存）和二级缓存（全局缓存）。
1. 一级缓存（Local Cache）
（1）核心定义
- 作用范围：单个 SqlSession 内部（会话级缓存），不同 SqlSession 互不共享。
- 存储介质：内存（HashMap），默认开启，无需额外配置。
（2）工作流程
- 同一
SqlSession执行相同查询（相同 SQL + 参数）：- 首次查询：查数据库，结果存入一级缓存。
- 二次查询：直接从缓存获取，不执行 SQL。
- 触发缓存清空的场景：
- 执行
insert/update/delete操作（自动清空当前 SqlSession 的一级缓存，保证数据一致性）。 - 调用
sqlSession.clearCache()手动清空。 - SqlSession 关闭（缓存失效）。
- 执行
（3）配置说明
默认开启，可通过 localCacheScope 调整作用域（全局配置）：
xml
2. 二级缓存（Second Level Cache）
（1）核心定义
- 作用范围：全局共享（跨 SqlSession），按 Mapper 接口（
namespace）隔离（同一 namespace 共享缓存）。 - 存储介质：默认内存（HashMap），可集成 Redis/Ehcache 等第三方缓存（持久化）。
- 依赖要求：缓存的实体类必须实现
Serializable接口（缓存对象需序列化存储）。
（2）工作流程
- 开启二级缓存后，
SqlSession关闭时，一级缓存中的数据会写入二级缓存。 - 新
SqlSession执行相同查询（同一 namespace + 相同 SQL + 参数）：- 先查二级缓存，命中则返回。
- 未命中则查数据库，结果存入一级缓存，
SqlSession关闭后同步到二级缓存。
- 触发缓存清空的场景：
- 同一 namespace 下执行
insert/update/delete操作（自动清空当前 namespace 的二级缓存）。 - 配置
flushInterval自动刷新（如 60 秒）。 - 手动调用
sqlSessionFactory.getConfiguration().getCache(namespace).clear()。
- 同一 namespace 下执行
（3）完整配置步骤
步骤 1：实体类实现 Serializable
java
运行
public class User implements Serializable { // 必须实现，否则缓存序列化失败
private Integer id;
private String username;
private List accounts;
// getter/setter/toString
} 步骤 2：全局开启二级缓存（SqlMapConfig.xml）
xml
步骤 3：Mapper 开启缓存（XML 方式）
在 Mapper XML 的 mapper 根标签下添加 <cache> 标签：
xml
flushInterval="60000"
size="1024"
readOnly="false"/>
UPDATE user SET username = #{username} WHERE id = #{id}
步骤 4：注解方式配置（备选）
java
运行
// UserMapper.java（注解开启二级缓存）
@CacheNamespace(
implementation = PerpetualCache.class, // 缓存实现类（默认）
eviction = LruCache.class, // 回收策略
flushInterval = 60000,
size = 1024,
readWrite = true // 等价于 readOnly="false"
)
public interface UserMapper {
@Options(useCache = true) // 启用二级缓存
User findUserById(@Param("id") Integer id);
@Options(flushCache = true) // 清空缓存
void updateUser(User user);
}（4）<cache> 标签核心属性
| 属性 | 取值说明 |
|---|---|
eviction | 缓存回收策略（4 种）：- LRU（默认）：最近最少使用，移除最长时间未使用对象- FIFO：先进先出，按存入顺序移除- SOFT：软引用，内存不足时移除- WEAK：弱引用，垃圾回收时移除 |
flushInterval | 自动刷新时间（毫秒），默认不自动刷新（仅增删改触发） |
size | 缓存最大对象数（默认 1024），需根据内存调整 |
readOnly | false（默认）：缓存对象可修改（返回序列化副本）；true：只读（返回原对象，性能更高） |
3. 一二级缓存核心对比
| 特性 | 一级缓存（Local Cache） | 二级缓存（Second Level Cache） |
|---|---|---|
| 作用范围 | 单个 SqlSession | 全局（跨 SqlSession），按 namespace 隔离 |
| 开启方式 | 默认开启，无需配置 | 全局开关 + Mapper 单独开启 |
| 存储介质 | 内存（HashMap） | 默认内存，可集成第三方缓存 |
| 序列化要求 | 无 | 实体类必须实现 Serializable |
| 数据一致性 | 会话内一致（自动清空） | 跨会话一致（增删改自动清空） |
| 适用场景 | 单次会话内重复查询 | 多会话共享数据（如字典、静态数据） |
4. 缓存使用注意事项
- 关联查询缓存一致性：如果 Mapper A 关联 Mapper B 的查询，建议 Mapper B 也开启二级缓存，避免关联数据缓存不一致。
- 禁用部分查询缓存：实时性要求高的数据（如订单状态），可通过
useCache="false"禁用二级缓存：xml
- 第三方缓存集成：生产环境建议用 Redis/Ehcache 替代默认内存缓存（默认缓存重启项目失效），需添加对应依赖（如
mybatis-redis）并配置缓存实现类。 - 避免缓存脏数据：多表关联查询（跨 namespace）不建议用二级缓存，容易因某张表更新未触发其他 namespace 缓存清空，导致脏数据。
三、延迟加载与缓存的协同工作
- 延迟加载的关联查询也会触发缓存：首次调用
getter执行关联查询后，结果会存入一级缓存，SqlSession关闭后同步到二级缓存。 - 缓存优先级：二级缓存 > 一级缓存 > 数据库（查询时先查二级缓存，再查一级缓存，最后查数据库）。
- 协同优化场景：查询主对象（如用户）时用延迟加载（避免关联数据冗余），主对象和关联对象均开启二级缓存（减少重复查询），适合 “主数据不常变、关联数据按需加载” 的场景（如用户信息 + 历史订单）。
浙公网安备 33010602011771号