1. Mybatis 延迟加载策略
1.1 何为延迟加载
就是在需要用到数据时才进行加载,不需要用到数据时就不加载数据。延迟加载也称懒加载。
- 好处:先从单表查询,需要时再从关联表去关联查询,大大提高数据库性能,因为查询单表要比关联查询多张表速度要快。
- 坏处 :因为只有当需要用到数据时,才会进行数据库查询,这样在大批量数据查询时,因为查询工作也要消耗时间,所以可能造成用户等待时间变长,造成用户体验下降。
1.2 实现需求
查询账户(Account)信息并且关联查询用户(User)信息。如果先查询账户(Account)信息即可满足要求,当我们需要查询用户(User)信息时再查询用户(User)信息。把对用户(User)信息的按需去查询就是延迟加载。
1.3 使用 assocation 实现延迟加载
1.3.1 在 Account 实体类中加入 user 属性
1 | /** |
1.3.2 账户的持久层 DAO 接口
1 | /** |
1.3.3 账户的持久层映射文件
1 |
|
1.3.4 用户的持久层接口和映射文件
1 | /** |
1 |
|
1.3.5 开启 Mybatis 的延迟加载策略
进入 Mybaits 的官方文档,找到 settings 的说明信息:
我们需要在 Mybatis 的配置文件 SqlMapConfig.xml 文件中添加延迟加载的配置。
1 | <!--配置参数--> |
1.3.6 编写测试只查账户信息不查用户信息
1 | /** |
测试结果如下:
我们发现,因为本次只是将Account对象查询出来放入List集合中,并没有涉及到User对象,所以就没有发出 SQL 语句查询账户所关联的 User 对象的查询。
1.4 使用 Collection 实现延迟加载
1.4.1 在 User 实体类中加入List<Account>
属性
1 | /** |
1.4.2 用户的持久层 DAO 接口
1 | /** |
1.4.3 用户的持久层映射文件
1 | <!-- 定义User的resultMap--> |
1.4.4 账户的持久层接口和映射文件
1 | /** |
1 | <!-- 根据用户id查询账户列表 --> |
1.4.5 编写测试只查用户信息不查账户信息
1 | /** |
测试结果如下:
我们发现并没有加载 Account 账户信息。
2. Mybatis 缓存
像大多数的持久化框架一样,Mybatis 也提供了缓存策略,通过缓存策略来减少数据库的查询次数,从而提高性能。
Mybatis 中缓存分为一级缓存,二级缓存。
2.1 Mybatis 一级缓存
2.1.1 证明一级缓存的存在
一级缓存是 SqlSession 级别的缓存,只要 SqlSession 没有 flush 或 close或clearCache,它就存在。
2.1.1.1 编写用户持久层 Dao 接口
1 | /** |
2.1.1.2 编写用户持久层映射文件
1 |
|
2.1.1.3 编写测试方法
1 | /** |
测试结果如下:
我们可以发现,虽然在上面的代码中我们查询了两次,但最后只执行了一次数据库操作,这就是 Mybatis 提供给我们的一级缓存在起作用了。因为一级缓存的存在,导致第二次查询 id为41的记录时,并没有发出sql语句从数据库中查询数据,而是从一级缓存中查询。
2.1.2 一级缓存的分析
一级缓存是 SqlSession 范围的缓存,当调用 SqlSession 的修改,添加,删除,commit(),close()等方法时,就会清空一级缓存。
第一次发起查询用户 id 为 1 的用户信息,先去找缓存中是否有 id 为 1 的用户信息,如果没有,从数据库查询用户信息。
得到用户信息,将用户信息存储到一级缓存中。
如果 sqlSession 去执行 commit 操作(执行插入、更新、删除),清空 SqlSession 中的一级缓存,这样做的目的为了让缓存中存储的是最新的信息,避免脏读。
第二次发起查询用户 id 为 1 的用户信息,先去找缓存中是否有 id 为 1 的用户信息,缓存中有,直接从缓存中获取用户信息。
2.1.3 测试一级缓存的清空
1 | /** |
1 | /** |
当执行sqlSession.close()后,再次获取sqlSession并查询id=41的User对象时,又重新执行了sql语句,从数据库进行了查询操作。
2.2 Mybatis 二级缓存
二级缓存是 mapper 映射级别的缓存,多个 SqlSession 去操作同一个 Mapper 映射的 sql 语句,多个SqlSession 可以共用二级缓存,二级缓存是跨 SqlSession 的。
2.2.1 二级缓存结构图
首先开启 mybatis 的二级缓存。
sqlSession1 去查询用户信息,查询到用户信息会将查询数据存储到二级缓存中。
如果 SqlSession3 去执行相同 mapper 映射下 sql,执行 commit 提交,将会清空该 mapper 映射下的二级缓存区域的数据。
sqlSession2 去查询与 sqlSession1 相同的用户信息,首先会去缓存中找是否存在数据,如果存在直接从缓存中取出数据。
2.2.2 二级缓存的开启与关闭
2.2.2.1 在 SqlMapConfig.xml 文件开启二级缓存
1 | <settings> |
2.2.2.2 配置相关的 Mapper 映射文件
1 |
|
2.2.2.3 配置 statement 上面的 useCache
1 | <!-- 根据id查询用户 --> |
2.2.3 二级缓存测试
1 | /** |
经过上面的测试,我们发现执行了两次查询,并且在执行第一次查询后,我们关闭了一级缓存,再去执行第二次查询时,我们发现并没有对数据库发出 sql 语句,所以此时的数据就只能是来自于我们所说的二级缓存。
2.2.4 二级缓存注意事项
当我们在使用二级缓存时,所缓存的类一定要实现 java.io.Serializable 接口,这种就可以使用序列化方式来保存对象。
3. Mybatis 注解开发
3.1 mybatis 的常用注解说明
1 | @Insert:实现新增 |
3.2 使用 Mybatis 注解实现基本 CRUD
3.2.1 编写实体类
1 | /** |
3.2.2 使用注解方式开发持久层接口
1 | /** |
3.2.3 编写 SqlMapConfig 配置文件
1 |
|
3.2.4 编写测试方法
1 | /** |
3.3 使用注解实现复杂关系映射开发
实现复杂关系映射之前我们可以在映射文件中通过配置<resultMap>
来实现,在使用注解开发时我们需要借助@Results 注解,@Result 注解,@One 注解,@Many 注解。
3.3.1 复杂关系映射的注解说明
1 | @Results 注解 |
3.3.2 使用注解实现一对一 复杂关系映射及延迟加载
加载账户信息时并且加载该账户的用户信息,根据情况可实现延迟加载。(注解方式实现)
3.3.2.1 添加 User 实体类及 Account 实体类
1 | /** |
1 | /** |
3.3.2.2 添加账户的持久层接口并使用注解配置
1 | /** |
3.3.2.3 添加用户的持久层接口并使用注解配置
1 | /** |
3.3.2.4 测试一对一关联及延迟加载
1 |
|
3.3.3 使用注解实现一对多复杂关系映射
查询用户信息时,也要查询他的账户列表。使用注解方式实现。
3.3.3.1 User 实体类加入List<Account>
1 | /** |
3.3.3.2 编写用户的持久层接口并使用注解配置
1 | /** |
3.3.3.3 编写账户的持久层接口并使用注解配置
1 | /** |
3.3.3.4 测试一对多关联及延迟加载
1 |
|
3.4 mybatis 基于注解的二级缓存
3.4.1 在 SqlMapConfig 中开启二级缓存支持
1 | <!-- 配置二级缓存 --> |
3.4.2 在持久层接口中使用注解配置二级缓存
1 | /** |
-------------本文结束感谢您的阅读-------------
本文标题: MyBatis(四)
本文链接: https://wgy1993.gitee.io/archives/bf2fe2d.html
版权声明: 本作品采用 CC BY-NC-SA 4.0 进行许可。转载请注明出处!