mybatis 鉴别其_MyBatis 示例-联合查询

最新推荐文章于 2023-02-12 14:46:38 发布

微基因WeGene

最新推荐文章于 2023-02-12 14:46:38 发布

阅读量122

点赞数

文章标签： mybatis 鉴别其

本文链接：https://blog.csdn.net/weixin_35875219/article/details/111921515

版权

本文介绍了MyBatis中的联合查询，包括嵌套查询和嵌套结果。嵌套查询可能导致N+1问题，影响性能。文中展示了嵌套查询中一对一、一对多和鉴别器的实现，并通过示例解释了延迟加载的工作原理。建议使用嵌套结果避免N+1问题，其通过一条SQL获取所有关联数据，性能更优。

摘要由CSDN通过智能技术生成

简介

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

微基因WeGene

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
mybatis 鉴别其_MyBatis 示例-联合查询

简介MyBatis 提供了两种联合查询的方式，一种是嵌套查询，一种是嵌套结果。先说结论：在项目中不建议使用嵌套查询，会出现性能问题，可以使用嵌套结果。测试类：com.yjw.demo.JointQueryTest，提供了对嵌套查询和嵌套结果的测试。数据库表模型关系学生信息级联模型关系：链接学生信息级联模型关系是一个多种类型关联关系，包含了如下几种情况：其中学生表是我们关注的中心，学生证表和它是一对...
复制链接

扫一扫