简介
MyBatis 提供了两种联合查询的方式,一种是嵌套查询,一种是嵌套结果。先说结论:在项目中不建议使用嵌套查询,会出现性能问题,可以使用嵌套结果。
测试类:com.yjw.demo.JointQueryTest,提供了对嵌套查询和嵌套结果的测试。
数据库表模型关系
学生信息级联模型关系:链接
学生信息级联模型关系是一个多种类型关联关系,包含了如下几种情况:
其中学生表是我们关注的中心,学生证表和它是一对一的关联关系;
而学生表和课程成绩表是一对多的关系,一个学生可能有多门课程;
课程表和课程成绩表也是一对多的关系;
学生有男有女,而健康项目也有所不一,所以女性学生和男性学生的健康表也会有所不同,这些是根据学生的性别来决定的,而鉴别学生性别的就是鉴别器。
关联关系
在联合查询中存在如下几种对应关系:一对一的关系;
一对多的关系;
多对多的关系,实际使用过程中是把多对多的关系分解为两个一对多的关系,以降低关系的复杂度;
还有一种是鉴别关系,比如我们去体检,男女有别,男性和女性的体检项目并不完全一样;
所以在 MyBatis 中联合分为这么3种:association、collection 和 discriminator。association:代表一对一关系;
collection:代表一对多关系;
discriminator:代表鉴别器,它可以根据实际选择采用哪种类作为实例,允许你根据特定的条件去关联不同的结果集;
嵌套查询(不建议使用)
一对一关系
以学生表作为关注的中心,学生表和学生证表是一对一的关系。POJO 对象和映射文件的实现如下:
StudentDO
public class StudentDO {
private Long id;
private String name;
private Sex sex;
private Long selfcardNo;
private String note;
private StudentSelfcardDO studentSelfcard;
// get set 方法}
StudentMapper.xml
typeHandler="com.yjw.demo.mybatis.common.type.SexEnumTypeHandler"/>
select="com.yjw.demo.mybatis.biz.dao.StudentSelfcardDao.listByConditions" />
一对一的关系建立通过 元素实现,该元素中的属性描述如下所示:property:JavaBean 中对应的属性字段;
column:数据库的列名或者列标签别名。与传递给 resultSet.getString(columnName) 的参数名称相同。注意: 在处理组合键时,您可以使用 column= "{prop1=col1,prop2=col2}" 这样的语法,设置多个列名传入到嵌套查询语句。这就会把 prop1 和 prop2 设置到目标嵌套选择语句的参数对象中;
select:通过这个属性,通过 ID 引用另一个加载复杂类型的映射语句。
fetchType: 设置局部延迟加载,它有两个取值范围,即 eager 和 lazy。它的默认值取决于你在配置文件settings 的配置,如果没有配置它,默认是 eager,一旦配置了,全局配置(lazyLoadingEnabled)就会被他们覆盖;
一对多关系
以学生表作为关注的中心,学生表和课程表是一对多的关系。POJO 对象和映射文件的实现如下:
StudentDO
public class StudentDO {
private Long id;
private String name;
private Sex sex;
private Long selfcardNo;
private String note;
private StudentSelfcardDO studentSelfcard;
private List studentLectures;
// get set 方法}
StudentMapper.xml
typeHandler="com.yjw.demo.mybatis.common.type.SexEnumTypeHandler"/>
select="com.yjw.demo.mybatis.biz.dao.StudentSelfcardDao.listByConditions" />
select="com.yjw.demo.mybatis.biz.dao.StudentLectureDao.listByConditions" />
一对一的关系建立通过 元素实现,该元素中的属性描述和 元素一样
鉴别器
以学生表作为关注的中心,不同性别的学生关联不同的健康指标。POJO 对象和映射文件的实现如下:
首先,我们需要新建两个健康情况的 POJO,即 StudentHealthMaleDO和 StudentHealthFemaleDO,分别存储男性和女性的基础信息,再新建两个 StudentDO 的子类:MaleStudentDO 和 FemaleStudentDO,关联健康情况的 POJO。
/*** 男生*/
public class MaleStudentDO extends StudentDO {
private List studentHealthMales;
// get set 方法}
/*** 女生*/
public class FemaleStudentDO extends StudentDO {
private List studentHealthFemales;
// get set 方法}
StudentMapper.xml
typeHandler="com.yjw.demo.mybatis.common.type.SexEnumTypeHandler"/>
select="com.yjw.demo.mybatis.biz.dao.StudentSelfcardDao.listByConditions" />
select="com.yjw.demo.mybatis.biz.dao.StudentLectureDao.listByConditions" />
select="com.yjw.demo.mybatis.biz.dao.StudentHealthMaleDao.listByConditions" />
select="com.yjw.demo.mybatis.biz.dao.StudentHealthFemaleDao.listByConditions" />
MyBatis 中的鉴别器通过 元素实现,它对应的列(column)是 sex,对应的 Java 类型(javaType)是 int,case 类似 Java 中的 switch 语句,当 sex=1(男性)时,引入的是 maleStudentMap1,当 sex=2(女性)时,引入的是 femaleStudentMap1,然后我们分别对这两个 resultMap 定义。
N+1 问题
嵌套查询存在 N+1 的问题,每次取一个 Student 对象,那么它所有的信息都会被取出来,这样会造成 SQL 执行过多导致性能下降。
我们通过日志信息来看一下嵌套查询 N+1 的问题:
2019-09-12 15:38:24.717 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : ==> Preparing: select * from t_student
2019-09-12 15:38:24.762 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : ==> Parameters:
2019-09-12 15:38:24.839 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, check_date, heart, liver, spleen, lung, kidney, prostate, note from t_student_health_male WHERE student_id = ?
2019-09-12 15:38:24.840 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 1(Long)
2019-09-12 15:38:24.843 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 1
2019-09-12 15:38:24.848 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, native_place, issue_date, end_date, note, student_effective from t_student_selfcard WHERE student_id = ?
2019-09-12 15:38:24.849 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 1(Long)
2019-09-12 15:38:24.852 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 1
2019-09-12 15:38:24.856 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, lecture_id, grade, note from t_student_lecture WHERE student_id = ?
2019-09-12 15:38:24.857 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 1(Long)
2019-09-12 15:38:24.859 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Preparing: select id, lecture_name, note from t_lecture where id = ?
2019-09-12 15:38:24.860 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Parameters: 1(Long)
2019-09-12 15:38:24.862 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : <====== Total: 1
2019-09-12 15:38:24.864 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Preparing: select id, lecture_name, note from t_lecture where id = ?
2019-09-12 15:38:24.864 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Parameters: 2(Long)
2019-09-12 15:38:24.867 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : <====== Total: 1
2019-09-12 15:38:24.868 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Preparing: select id, lecture_name, note from t_lecture where id = ?
2019-09-12 15:38:24.869 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : ======> Parameters: 3(Long)
2019-09-12 15:38:24.870 DEBUG 2660 --- [ main] c.y.d.m.b.d.LectureDao.getByPrimaryKey : <====== Total: 1
2019-09-12 15:38:24.871 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 3
2019-09-12 15:38:24.874 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, check_date, heart, liver, spleen, lung, kidney, uterus, note from t_student_health_female WHERE student_id = ?
2019-09-12 15:38:24.875 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 2(Long)
2019-09-12 15:38:24.878 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 1
2019-09-12 15:38:24.879 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, native_place, issue_date, end_date, note, student_effective from t_student_selfcard WHERE student_id = ?
2019-09-12 15:38:24.879 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 2(Long)
2019-09-12 15:38:24.881 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 1
2019-09-12 15:38:24.882 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, lecture_id, grade, note from t_student_lecture WHERE student_id = ?
2019-09-12 15:38:24.882 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 2(Long)
2019-09-12 15:38:24.886 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 3
2019-09-12 15:38:24.887 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, check_date, heart, liver, spleen, lung, kidney, prostate, note from t_student_health_male WHERE student_id = ?
2019-09-12 15:38:24.887 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 3(Long)
2019-09-12 15:38:24.893 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 0
2019-09-12 15:38:24.894 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, native_place, issue_date, end_date, note, student_effective from t_student_selfcard WHERE student_id = ?
2019-09-12 15:38:24.897 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 3(Long)
2019-09-12 15:38:24.899 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 0
2019-09-12 15:38:24.900 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Preparing: select id, student_id, lecture_id, grade, note from t_student_lecture WHERE student_id = ?
2019-09-12 15:38:24.901 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : ====> Parameters: 3(Long)
2019-09-12 15:38:24.908 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listByConditions : <==== Total: 0
2019-09-12 15:38:24.909 DEBUG 2660 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : <== Total: 3
学生数据有3条,在查询学生证件、学生成绩等这些信息的时候,分别执行了3次,每次都用 id = ? 执行,如果学生数据比较多时,严重影响性能。
为了处理嵌套查询带来的 N+1 的问题,MyBatis 引入了延迟加载的功能。在 MyBatis 的配置中有两个全局的参数 lazyLoadingEnabled、aggressiveLazyLoading。
我们设置延迟加载的全局开关(lazyLoadingEnabled)为 true 的时候,当访问学生信息的时候,MyBatis 已经把学生的健康情况也查询出来了,当访问学生的课程信息的时候,MyBatis 同时也把其学生证信息查询出来了,为什么是这样一个结果呢?因为在默认情况下 MyBatis 是按层级延迟加载的,让我们看看这个延迟加载的层级:
这不是我们需要的加载数据方式,我们不希望在访问学生信息的时候去加载学生的健康情况数据。那么这个时候就需要设置 aggressiveLazyLoading 属性了,当它为 true 的时候,MyBatis 的内容按层级加载,否则就按我们调用的要求加载。
这两项配置既可以在 Spring Boot 配置文件中配置,也可以在 MyBatis 配置文件中配置,在 setting 元素中加入下面的代码:
按需加载的意思是我们不手动调用对应的属性,就不会加载。通过执行如下测试代码来演示一下按需加载的功能:
/*** 联合查询-嵌套查询(一对一、一对多、鉴别器)** @throws JsonProcessingException*/
@Test
public void listStudentByNestingQuery() throws JsonProcessingException, InterruptedException {
List students = studentDao.listStudentByNestingQuery();
Thread.sleep(3000L);
System.out.println("睡眠3秒钟");
students.get(0).getStudentSelfcard();
}
在查询完学生信息的时候,我们睡眠了3秒钟,再调学生证件信息,来看下日志的输出:
2019-09-12 16:24:46.341 INFO 16772 --- [ main] com.alibaba.druid.pool.DruidDataSource : {dataSource-1} inited
2019-09-12 16:24:46.355 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : ==> Preparing: select * from t_student
2019-09-12 16:24:46.402 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : ==> Parameters:
2019-09-12 16:24:46.630 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listStudentByNestingQuery : <== Total: 3
睡眠3秒钟
2019-09-12 16:24:49.655 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listByConditions : ==> Preparing: select id, student_id, native_place, issue_date, end_date, note, student_effective from t_student_selfcard WHERE student_id = ?
2019-09-12 16:24:49.659 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listByConditions : ==> Parameters: 1(Long)
2019-09-12 16:24:49.666 DEBUG 16772 --- [ main] c.y.d.m.b.d.S.listByConditions : <== Total: 1
看上面的日志输出,延迟加载的配置实现了按需加载的功能。但是嵌套查询还是不建议使用,因为不可控,我们不确定哪些操作会导致 N+1 的问题,比如如果我们使用了 JSON 的工具把查出来的学生信息转成 JSON 字符串的时候,就会导致查询出学生的所有关联信息。
/*** 联合查询-嵌套查询(一对一、一对多、鉴别器)** @throws JsonProcessingException*/
@Test
public void listStudentByNestingQuery() throws JsonProcessingException, InterruptedException {
List students = studentDao.listStudentByNestingQuery();
// 1.测试延迟加载的效果 // Thread.sleep(3000L); // System.out.println("睡眠3秒钟"); // students.get(0).getStudentSelfcard();
// 2.使用JSON功能转JSON字符串会导致N+1的问题 System.out.println(JsonUtils.toJSONString(students));
}
日志输出和没有使用延迟加载配置的效果一样,其实这里的配置是没有问题的,只是 JSON 工具在生成 JSON 字符串的时候,会逐层调用数据,所以就导致了需要把学生的所有关联信息都查出来。
嵌套结果
MyBatis 还提供了另外一种关联查询的方式(嵌套结果),这种方式更为简单和直接,没有 N+1 的问题,因为它的数据是一条 SQL 查出来的,代码如下所示。
嵌套结果中的一对一、一对多、鉴别器和嵌套查询类似,只是不引用外部的 select 语句,属性都配置在了一个 resultMap 中。
SELECT s.id,s.name,s.sex,s.note,s.selfcard_no,
if(sex=1,shm.id,shf.id) AS hid,
if(sex=1,shm.check_date,shf.check_date) AS check_date,
if(sex=1,shm.heart,shf.heart) AS heart,
if(sex=1,shm.liver,shf.liver) AS liver,
if(sex=1,shm.spleen,shf.spleen) AS spleen,
if(sex=1,shm.lung,shf.lung) AS lung,
if(sex=1,shm.kidney,shf.kidney) AS kidney,
if(sex=1,shm.note,shf.note) AS shnote,
shm.prostate,shf.uterus,
ss.id AS ssid,ss.native_place,
ss.issue_date,ss.end_date,ss.note AS ssnote,
sl.id AS slid,sl.grade,sl.note AS slnote,
l.lecture_name,l.note AS lnote
FROM t_student s
LEFT JOIN t_student_health_male shm ON s.id=shm.student_id
LEFT JOIN t_student_health_female shf ON s.id = shf.student_id
LEFT JOIN t_student_selfcard ss ON s.id = ss.student_id
LEFT JOIN t_student_lecture sl ON s.id=sl.student_id
LEFT JOIN t_lecture l ON sl.lecture_id = l.id
collection 元素中的 ofType 属性定义的是 collection 里面的 Java 类型。架构笔记 · 语雀www.yuque.com