MyBatis-Plus-Join 快速上手指南：让多表查询不再“复杂”，只需一点点魔法！

Posted 14 days ago Updated 15 days ago

By Administrator

16~21 min read

在我们面对一个复杂的业务需求时，数据库多表联合查询往往是难以避免的话题。传统的 MyBatis 或者 MyBatis-Plus 本身对单表操作非常友好，但一旦遇到需要“联合查询”的需求时，可能不少人会感到头痛：要么手动拼 SQL，要么写一堆 ResultMap，甚至是直接使用 Native SQL，维护起来相当麻烦。

别担心！今天，我要带你了解一款“魔法工具”—— MyBatis-Plus-Join，它将让多表联查变得优雅而轻松。这不仅仅是一个上手指南，更是一次“让代码少一些痛苦、多一些优雅”的旅程。希望你读完这篇文章后，能对这个轻量级扩展框架有全新的认识。

一、什么是 MyBatis-Plus-Join？

MyBatis-Plus-Join（以下简称 MPJ），是 MyBatis-Plus 的一个功能拓展库，专注于解决 “多表联合查询” 的问题。它通过封装常用的多表查询逻辑，结合 Lambda 表达式风格的链式语法，让你在查询时不再需要书写复杂的 SQL，也不需要手动处理数据库字段和 Java 对象之间的映射关系。

核心优势：

零 SQL：使用 Java 代码构建 Join 查询，不需要手动写 Join 语句。
强类型：使用 Lambda 表达式进行字段映射，减少字段名错误。
自动映射：查询出的字段会自动映射到对应的实体或 DTO。
兼容 MP 原生查询：可以结合 QueryWrapper 一起使用。
支持主流数据库：MySQL、PostgreSQL、Oracle 等。

二、实战演练：从零搭建一个 Join 查询

场景设定

我们有三个表：

User（用户表）：
- user_id
- username
- dept_id
Department（部门表）：
- dept_id
- dept_name
Role（角色表）：
- role_id
- role_name

目标是从 User 表出发，关联查出 Department（左连接）和 Role（内部连接）的信息，并组装为一个 DTO 返回。

1. 引入依赖

你需要先引入 MPJ 的核心依赖（基于 Spring Boot 的项目）：

<dependency>
    <groupId>org.dromara.mpj</groupId>
    <artifactId>mybatis-plus-join-boot-starter</artifactId>
    <version>1.3.2</version>
</dependency>

确保你已经引入了 MyBatis-Plus Starter。

2. 编写 Entity（简化起见，这里不做展开）

@Data
public class User {
    private Long userId;
    private String username;
    private Long deptId;
}

@Data
public class Department {
    private Long deptId;
    private String deptName;
}

@Data
public class Role {
    private Long roleId;
    private String roleName;
}

3. 定义返回结果 DTO

@Data
public class UserWithDeptAndRole {
    private String username;
    private String deptName;
    private String roleName;
}

4. 构建 MPJ 查询

在 Service 或 Mapper 中，使用 MPJ 的查询风格如下：

import org.dromara.mpj.mpjoin.wrapper.MPJJoinWrapper;

import org.dromara.mpj.mpjoin.entity.MPJResult;

import java.util.List;

public List<UserWithDeptAndRole> getUsersWithDeptAndRole() {

    return userMapper.selectJoinList(UserWithDeptAndRole.class, new MPJJoinWrapper<User>()

        .select(User::getUsername)  // select user.username

        .select(Department::getDeptName)  // select department.dept_name

        .select(Role::getRoleName)  // select role.role_name

        .leftJoin(Department.class, on -> on.eq(User::getDeptId, Department::getDeptId)) // left join department

        .innerJoin(Role.class, on -> on.eq(User::getRoleId, Role::getRoleId)) // inner join role

    );

}

✅ Tips：这里的查询语句完全由 Java 链式构建，字段用方法引用来表达条件，避免硬编码字段名。不仅结构清晰，还不容易拼错字段！

5. 简洁的返回结果

MPJ 自动将数据库字段映射到 DTO 对应的字段名，无需手动处理。

三、MPJ 的几个核心设计思想

1. 少写 SQL，多做业务

MPJ 的理念是 减少无意义的 SQL 重复劳动。开发者更多关注业务逻辑，而不是 SQL 编写本身。这在中大型项目尤为实用，特别是当表的结构频繁变更时。

2. 零反射，运行更快

许多 ORM 或扩展库大量依赖反射机制，造成性能损耗。MPJ 尽可能使用编译期的 Lambda 表达式处理字段，性能开销极低。

3. 保持与 MyBatis-Plus 的高度集成

MPJ 在设计上保持了对 MP 原本 QueryWrapper、Wrapper 查询风格的兼容性，可以非常自然地嵌入已有项目。

四、我对 MPJ 的一些思考：多表查询该“优雅”到什么程度？

作为一名 Java 后端开发爱好者，我一直在思考：

“多表联合查询，真的只能靠硬编码 SQL 吗？”

MPJ 想要做的正是打破这种僵局。它不是一种革命，而是一种温和的优化方式——一种让多表查询也能保持“强类型”语言优势的方式。

我们当然可以在复杂查询场景下使用 SQL，但当查询逻辑相对简单、变动频繁、表结构多变时，使用 MPJ 能提供 更高的开发效率 和 更低的维护成本。

它不是为了完全取代 SQL，而是为了让我们少写一些可以避免的 SQL。

五、给你的建议 & 总结

使用建议：

适合场景：多表联查、需要自动映射字段、避免写 Join SQL 的项目。
不适合场景：极其复杂的、需要优化执行计划或需要动态拼接大量条件的查询。

结语：让代码更聪明一点

MyBatis-Plus-Join 就像是一把“轻剑”，不会喧宾夺主，但它会让你的代码更精致、更智能。当你看到一个复杂的 Join 查询只需几行清晰的 Java 代码就完成了，你会不由自主地对它说一声：“这，是开发本该有的样子。”

所以，尝试一下 MyBatis-Plus-Join，它或许就是你一直在找的那一行代码的灵感。

后端

Java

License: CC BY 4.0