1. 项目概述为什么我们需要深入理解 Wrapper如果你用过 MyBatis-Plus那你肯定绕不开Wrapper这个核心组件。它绝不仅仅是一个用来拼接 SQL WHERE 条件的工具类。在我经手过的十几个中后台项目中但凡涉及到复杂查询、动态条件构建或者数据权限控制Wrapper都扮演着至关重要的角色。很多开发者尤其是刚接触 MyBatis-Plus 的朋友往往只停留在eq、like、between这几个基础方法的使用上一旦遇到多表关联、子查询或者需要高度定制化的查询逻辑时就容易抓瞎要么退回去写原生 XML要么写出极其冗长且难以维护的代码。实际上Wrapper的设计哲学是“以对象的方式操作 SQL 条件”它提供了一套类型安全、链式调用的 API将我们从繁琐且易错的字符串拼接中解放出来。更重要的是它是 MyBatis-Plus 诸多高级特性如逻辑删除、多租户、数据权限的基石。不理解Wrapper就很难用好 MyBatis-Plus 的完整能力。今天我们就抛开官方文档那点到为止的介绍从一个多年实战者的角度彻底拆解Wrapper的里里外外分享那些官方没写但实际开发中天天在用的技巧和避坑指南。2. Wrapper 核心体系与设计思想拆解2.1 家族图谱认识三大核心 WrapperMyBatis-Plus 的Wrapper是一个抽象体系最常用的是它的三个子类QueryWrapper、UpdateWrapper和LambdaQueryWrapper/LambdaUpdateWrapper。很多人一开始会混淆我们直接看它们的核心分工QueryWrapperT: 专用于查询SELECT操作的条件封装。你可以用它来构建WHERE、ORDER BY、GROUP BY等子句。它是功能最全、最基础的查询条件包装器。UpdateWrapperT: 专用于更新UPDATE操作。除了能封装WHERE条件它最关键的能力是使用set()方法直接指定要更新的字段和值无需将要更新的字段设置为实体对象的属性。这在“只更新特定几个字段而实体对象其他属性为null”的场景下非常有用。LambdaXxxWrapper: 这是QueryWrapper和UpdateWrapper的“语法糖”版本。它通过 Lambda 表达式引用实体类的属性例如LambdaQueryWrapperUser::eq(User::getName, 张三)。最大的好处是编译期类型安全和IDE智能提示。你不再需要手写数据库字段名的字符串避免了因字段名拼写错误导致的运行时异常。在项目实践中我强烈推荐在新代码中优先使用 Lambda 版本。它们之间的关系和选择可以总结为下表特性QueryWrapper / UpdateWrapperLambdaQueryWrapper / LambdaUpdateWrapper核心用途构建查询/更新条件构建查询/更新条件类型安全条件指定方式字符串字段名 (如name)Lambda 方法引用 (如User::getName)类型安全否运行时可能出错是编译期检查重构友好性差字段名修改需全局搜索替换好IDE自动重构推荐场景动态表名、极度灵活的SQL拼接等绝大多数常规场景注意虽然 Lambda 方式更安全但在一些需要动态传入字段名的极端场景下比如通用导出功能字段名来自前端配置字符串方式的QueryWrapper仍是必要的。但这种情况在良好设计的业务系统中并不常见。2.2 链式调用与条件组合的精髓Wrapper的 API 设计采用了流畅的链式调用Fluent API。这意味着你可以在一个语句中连续调用多个方法代码读起来就像在描述 SQL 逻辑本身。// 一个典型的链式调用示例查找年龄大于18且姓“张”或者状态为激活的用户按年龄倒序 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.gt(User::getAge, 18) .likeRight(User::getName, 张) // likeRight 表示 name LIKE 张% .or() .eq(User::getStatus, 1) .orderByDesc(User::getAge);这段代码对应的 SQL 思想是WHERE (age 18 AND name LIKE 张%) OR status 1 ORDER BY age DESC。这里有几个关键点and()与or()的隐式与显式默认情况下连续调用eq(),gt()等方法它们之间是AND关系。当你需要引入OR逻辑时必须显式地调用or()方法。or()方法非常关键它表示后续条件将与前面的条件以OR连接。条件分组上面的例子中or()把整个条件分成了两部分。但有时我们需要更复杂的逻辑比如(A AND B) OR (C AND D)。这时就需要引入nested()方法进行嵌套或者使用带Consumer参数的方法如and(i - i.eq(...).gt(...))来构建子条件组。这是Wrapper进阶使用的核心后面会详细讲。链式调用的顺序就是 SQL 的顺序你写 wrapper 的顺序基本决定了最终 SQL 条件子句的顺序。这要求开发者对 SQL 逻辑有清晰的认识。实操心得在编写复杂Wrapper时我习惯先在纸上或注释里写出目标 SQL 的WHERE部分然后再转化为Wrapper代码。这能有效避免逻辑错误。另外对于超过 5 个条件的复杂查询务必使用 Lambda 版本来减少错误并多加注释说明业务逻辑。3. 核心条件构造方法深度解析Wrapper提供了数十个条件构造方法我们不可能面面俱到但必须掌握其中最核心、最容易用错的一组。3.1 等值、范围与模糊查询这是最基础也是最常用的部分。eq/ne: 等于 / 不等于。注意null值的处理eq(null)在大部分数据库驱动下会生成IS NULL但行为可能不一致最稳妥的方式是使用isNull()方法。gt/ge/lt/le: 大于 / 大于等于 / 小于 / 小于等于。常用于数字和日期比较。between/notBetween: 介于之间。参数是(column, val1, val2)注意它是闭区间[val1, val2]。like/notLike: 模糊匹配。这里有一个大坑like(“name”, “%张%”)是可以的但更推荐使用likeLeft、likeRight。likeRight(“name”, “张”): 生成name LIKE ‘张%’匹配以“张”开头。这是最常用的。likeLeft(“name”, “三”): 生成name LIKE ‘%三’匹配以“三”结尾。直接使用like时你需要自己处理百分号而likeRight/Left语义更清晰且能利用索引当使用likeRight且字段有索引时。3.2 空值处理与 IN 查询isNull/isNotNull: 专门处理NULL值。比在eq中传入null更明确。in/notIn: 集合查询。in(“role_id”, Arrays.asList(1, 2, 3))。关键技巧当传入的集合为空时MyBatis-Plus 默认会怎么处理在 3.x 版本中如果集合为空in条件会被忽略即不生效这通常会导致查询出全部数据这可能是你期望的也可能是个 bug为了安全我总是在调用in前显式判断集合是否为空if (!CollectionUtils.isEmpty(roleIds)) { wrapper.in(UserRole::getRoleId, roleIds); } else { // 根据业务决定可能是查询无结果也可能是忽略此条件 wrapper.eq(“1”, “0”); // 强制让查询无结果例如 WHERE 10 }3.3 嵌套、或逻辑与子查询进阶核心这是区分普通使用者和高阶使用者的分水岭。复杂的 AND/OR 混合逻辑 假设我们需要查询(status1 AND type IN (1,2)) OR (status2 AND create_time ‘2023-01-01’)。 错误的写法是连续调用or()那会得到错误的逻辑。正确的写法是使用nested或and/or的消费者模式// 方法一使用 nested (清晰但稍显冗长) wrapper.nested(i - i.eq(User::getStatus, 1).in(User::getType, Arrays.asList(1, 2))) .or() .nested(j - j.eq(User::getStatus, 2).gt(User::getCreateTime, LocalDate.of(2023,1,1)))); // 方法二使用 and/or 的 Consumer 参数更简洁推荐 wrapper.and(i - i.eq(User::getStatus, 1).in(User::getType, Arrays.asList(1, 2))) .or(j - j.eq(User::getStatus, 2).gt(User::getCreateTime, LocalDate.of(2023,1,1)));and(Consumer)和or(Consumer)方法会创建一个新的子Wrapper在这个子Wrapper中构建的条件会被括号包裹起来完美实现了条件分组。子查询Wrapper支持通过inSql,notInSql,exists,notExists等方法进行子查询。这功能非常强大。// 查询存在订单的用户 wrapper.exists(“SELECT 1 FROM order WHERE order.user_id user.id”); // 使用 inSql: 查询角色为“管理员”的用户 wrapper.inSql(“id”, “SELECT user_id FROM user_role WHERE role_id (SELECT id FROM role WHERE name ‘admin’)”);注意事项子查询字符串需要你自己保证正确性Wrapper不会帮你做任何转义或校验。在涉及多租户或逻辑删除时要特别注意子查询 SQL 是否会自动附加这些全局条件通常不会需要手动处理。3.4 UpdateWrapper 的 setSql 妙用UpdateWrapper除了能用set(“column”, value)设置固定值还有一个利器setSql。它允许你设置一个 SQL 片段用于执行字段的表达式更新。// 将用户的积分增加 10 UpdateWrapperUser updateWrapper new UpdateWrapper(); updateWrapper.eq(“id”, 1L) .setSql(“points points 10”); // 直接使用 SQL 表达式 // 等同于 SQL: UPDATE user SET points points 10 WHERE id 1 userMapper.update(null, updateWrapper); // 注意第一个实体参数为null这个功能在实现“原子性增减”、“更新版本号”等场景时非常有用避免了“先查询再计算最后更新”的非原子操作也减少了数据库往返次数。4. 实战结合分页、数据权限与自定义 SQL4.1 与分页插件 Page 无缝协作MyBatis-Plus 的分页插件PaginationInnerInterceptor和Wrapper是天作之合。通常我们这样用// 1. 构建分页对象 PageUser page new Page(1, 10); // 当前页每页大小 // 可以设置是否进行 count 查询优化大数据量分页性能 // page.setSearchCount(false); // 2. 构建查询条件 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getDepartmentId, 5) .orderByDesc(User::getCreateTime); // 3. 执行分页查询 PageUser resultPage userMapper.selectPage(page, wrapper); // 获取数据 ListUser records resultPage.getRecords(); long total resultPage.getTotal();这里有个性能优化点对于非常复杂的查询selectPage会自动执行两条 SQL一条COUNT(*)查询总数一条带LIMIT的分页查询数据。如果总数计算非常慢比如关联表多、条件复杂而你又不关心总条数只想要“下一页”数据可以通过page.setSearchCount(false)来禁用 count 查询提升性能。4.2 实现数据权限过滤核心实战这是Wrapper在复杂企业级应用中最闪耀的场景之一。假设我们有这样一个需求用户只能看到自己所在部门及子部门的数据。我们通常不希望在每一个查询业务代码里都手动添加这个条件而是希望通过一种全局的、无侵入的方式实现。MyBatis-Plus 提供了InnerInterceptor接口我们可以实现一个数据权限拦截器。其核心原理就是在 SQL 执行前动态地向Wrapper添加条件。Component public class DataPermissionInterceptor implements InnerInterceptor { Override public void beforeQuery(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { // 1. 判断是否需要添加数据权限例如通过注解或URI判断 if (!needDataPermission(ms)) { return; } // 2. 获取当前用户的部门ID列表从ThreadLocal或SecurityContext中 ListLong accessibleDeptIds getCurrentUserDeptIds(); // 3. 找到参数中的 QueryWrapper if (parameter instanceof Map) { Map?, ? paramMap (Map?, ?) parameter; paramMap.forEach((key, value) - { // 寻找名为‘ew’的参数这是MyBatis-Plus自动包装的Wrapper参数名 if (value instanceof QueryWrapper) { QueryWrapper? wrapper (QueryWrapper?) value; // 4. 动态添加部门过滤条件 wrapper.in(“department_id”, accessibleDeptIds); } else if (value instanceof LambdaQueryWrapper) { LambdaQueryWrapper? wrapper (LambdaQueryWrapper?) value; // 这里需要知道实体类型通用处理较复杂通常需要借助反射或约定 // 一种更通用的做法是始终使用QueryWrapper或者在特定属性上做处理 } }); } // 对于 UpdateWrapper 和 DeleteWrapper逻辑类似在 beforeUpdate/beforeDelete 中处理 } // ... 其他方法实现 }然后将这个拦截器配置到 MyBatis-Plus 的拦截器链中。这样所有相关的查询都会自动带上department_id IN (...)的条件实现了数据隔离。注意事项这种方式对直接使用mapper.selectByMap()或手写 XML 中 SQL 可能不生效需要根据情况做特殊处理或约定规范。4.3 对接 XML 中的自定义复杂 SQL有时极度复杂的查询如涉及多重嵌套子查询、特定数据库函数、优化提示仍需写在 XML 映射文件中。Wrapper同样可以与此模式协同工作。在 Mapper 接口中你可以这样定义方法// 在 UserMapper.java 中 ListUser selectUsersWithCustomCondition(Param(“ew”) QueryWrapperUser wrapper);在对应的UserMapper.xml中select id“selectUsersWithCustomCondition” resultType“User” SELECT u.*, d.name as dept_name FROM user u LEFT JOIN department d ON u.dept_id d.id -- 关键在这里使用 ${ew.customSqlSegment} ${ew.customSqlSegment} /select调用时QueryWrapperUser wrapper new QueryWrapper(); wrapper.eq(“u.status”, 1) .like(“d.name”, “研发”) .orderByDesc(“u.create_time”); ListUser list userMapper.selectUsersWithCustomCondition(wrapper);最终执行的 SQL 会是SELECT u.*, d.name as dept_name FROM user u LEFT JOIN department d ON u.dept_id d.id WHERE u.status 1 AND d.name LIKE ‘%研发%’ ORDER BY u.create_time DESC重要提示${ew.customSqlSegment}是直接拼接 SQL 片段要警惕 SQL 注入风险。但Wrapper内部在生成customSqlSegment时已经对参数进行了预编译处理使用?占位符因此通过Wrapper方法设置的条件是安全的。然而如果你手动通过wrapper.apply(“some_sql”)添加了原生 SQL 片段则需要自己确保该片段的安全性。5. 性能调优、常见陷阱与排查指南5.1 索引失效与 N1 查询问题索引失效Wrapper生成的 SQL 质量取决于你怎么用。负面案例wrapper.like(“name”, “%张三%”)如果name字段有索引前导百分号会导致索引失效。应尽量使用likeRight(“name”, “张”)。负面案例对字段进行函数操作如wrapper.apply(“DATE(create_time) ‘2023-10-01’”)这会使create_time上的索引失效。应改为范围查询wrapper.ge(“create_time”, “2023-10-01”).lt(“create_time”, “2023-10-02”)。or条件WHERE a1 OR b2如果a和b都有单列索引数据库可能不会使用索引。需要考虑使用UNION或调整查询设计。N1 查询问题这不是Wrapper独有的但在使用 MyBatis-Plus 的关联查询如TableField(existfalse)配合额外查询时容易发生。Wrapper本身不解决此问题。解决方案是使用上一节提到的自定义SQLWrapper进行 join 查询一次获取所有数据。使用 MyBatis-Plus 的TableField(select false)并手动在 Service 层做批量查询组装。考虑使用专门的关联查询插件如早期版本的join功能或第三方扩展。5.2 条件为空时的处理策略这是一个非常常见的陷阱。比如前端传回的查询参数对象很多字段是可选的。UserQueryParam param ...; // 来自前端的参数 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); if (StringUtils.isNotBlank(param.getName())) { wrapper.like(User::getName, param.getName()); } if (param.getStatus() ! null) { wrapper.eq(User::getStatus, param.getStatus()); } // ... 更多条件如果所有条件都为空wrapper就是一个“空”条件最终 SQL 会是SELECT * FROM user这可能返回海量数据引发性能问题。必须增加一个兜底策略添加一个永假条件不推荐影响可读性wrapper.eq(“1”, “0”)。在业务层进行判断如果所有条件为空则直接返回空列表或抛出参数异常。强制要求分页即使条件为空也必须有分页参数限制结果集大小最推荐。5.3 日志排查与 SQL 调试MyBatis-Plus 默认配置下执行的 SQL 会打印到日志。但有时我们需要更清晰地看到Wrapper最终生成的 SQL 片段和参数。开启完整 SQL 日志在application.yml中配置mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 控制台打印完整SQL带?占位符或者使用p6spy等第三方组件可以打印出替换参数后的真实 SQL。直接获取 SQL 片段在调试代码时你可以直接调用wrapper.getCustomSqlSegment()和wrapper.getParamNameValuePairs()来查看Wrapper生成的 WHERE 条件片段和参数映射这有助于理解复杂条件组合后的结果。常见错误对照表现象可能原因解决方案查询结果与预期不符and()/or()逻辑嵌套错误使用nested()或and(Consumer)/or(Consumer)明确分组更新了所有记录UpdateWrapper没有设置where条件务必在更新前确认wrapper包含了有效的where条件参数绑定异常Lambda 表达式引用错误如引用非 getter 方法确保使用正确的实体类属性和方法引用性能突然变慢生成了导致索引失效的 SQL如LIKE ‘%xx’检查Wrapper条件使用EXPLAIN分析 SQL分页总数查询慢关联表多或条件复杂考虑page.setSearchCount(false)或优化 count 语句5.4 自定义全局条件处理除了数据权限Wrapper还可以方便地处理一些全局逻辑比如逻辑删除和多租户。MyBatis-Plus 内置了这些功能的拦截器。以逻辑删除为例你只需要在实体字段上加TableLogic并在配置中开启逻辑删除。之后你所有的delete操作都会变为update set deleted1所有的select操作都会自动加上AND deleted0条件。这个自动添加的条件就是通过Wrapper的机制在底层实现的。理解这一点有助于你在需要“忽略逻辑删除条件”进行查询时如管理后台知道如何使用wrapper.ignoreLogicDelete()等方法。
1. 项目概述为什么我们需要深入理解 Wrapper如果你用过 MyBatis-Plus那你肯定绕不开Wrapper这个核心组件。它绝不仅仅是一个用来拼接 SQL WHERE 条件的工具类。在我经手过的十几个中后台项目中但凡涉及到复杂查询、动态条件构建或者数据权限控制Wrapper都扮演着至关重要的角色。很多开发者尤其是刚接触 MyBatis-Plus 的朋友往往只停留在eq、like、between这几个基础方法的使用上一旦遇到多表关联、子查询或者需要高度定制化的查询逻辑时就容易抓瞎要么退回去写原生 XML要么写出极其冗长且难以维护的代码。实际上Wrapper的设计哲学是“以对象的方式操作 SQL 条件”它提供了一套类型安全、链式调用的 API将我们从繁琐且易错的字符串拼接中解放出来。更重要的是它是 MyBatis-Plus 诸多高级特性如逻辑删除、多租户、数据权限的基石。不理解Wrapper就很难用好 MyBatis-Plus 的完整能力。今天我们就抛开官方文档那点到为止的介绍从一个多年实战者的角度彻底拆解Wrapper的里里外外分享那些官方没写但实际开发中天天在用的技巧和避坑指南。2. Wrapper 核心体系与设计思想拆解2.1 家族图谱认识三大核心 WrapperMyBatis-Plus 的Wrapper是一个抽象体系最常用的是它的三个子类QueryWrapper、UpdateWrapper和LambdaQueryWrapper/LambdaUpdateWrapper。很多人一开始会混淆我们直接看它们的核心分工QueryWrapperT: 专用于查询SELECT操作的条件封装。你可以用它来构建WHERE、ORDER BY、GROUP BY等子句。它是功能最全、最基础的查询条件包装器。UpdateWrapperT: 专用于更新UPDATE操作。除了能封装WHERE条件它最关键的能力是使用set()方法直接指定要更新的字段和值无需将要更新的字段设置为实体对象的属性。这在“只更新特定几个字段而实体对象其他属性为null”的场景下非常有用。LambdaXxxWrapper: 这是QueryWrapper和UpdateWrapper的“语法糖”版本。它通过 Lambda 表达式引用实体类的属性例如LambdaQueryWrapperUser::eq(User::getName, 张三)。最大的好处是编译期类型安全和IDE智能提示。你不再需要手写数据库字段名的字符串避免了因字段名拼写错误导致的运行时异常。在项目实践中我强烈推荐在新代码中优先使用 Lambda 版本。它们之间的关系和选择可以总结为下表特性QueryWrapper / UpdateWrapperLambdaQueryWrapper / LambdaUpdateWrapper核心用途构建查询/更新条件构建查询/更新条件类型安全条件指定方式字符串字段名 (如name)Lambda 方法引用 (如User::getName)类型安全否运行时可能出错是编译期检查重构友好性差字段名修改需全局搜索替换好IDE自动重构推荐场景动态表名、极度灵活的SQL拼接等绝大多数常规场景注意虽然 Lambda 方式更安全但在一些需要动态传入字段名的极端场景下比如通用导出功能字段名来自前端配置字符串方式的QueryWrapper仍是必要的。但这种情况在良好设计的业务系统中并不常见。2.2 链式调用与条件组合的精髓Wrapper的 API 设计采用了流畅的链式调用Fluent API。这意味着你可以在一个语句中连续调用多个方法代码读起来就像在描述 SQL 逻辑本身。// 一个典型的链式调用示例查找年龄大于18且姓“张”或者状态为激活的用户按年龄倒序 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.gt(User::getAge, 18) .likeRight(User::getName, 张) // likeRight 表示 name LIKE 张% .or() .eq(User::getStatus, 1) .orderByDesc(User::getAge);这段代码对应的 SQL 思想是WHERE (age 18 AND name LIKE 张%) OR status 1 ORDER BY age DESC。这里有几个关键点and()与or()的隐式与显式默认情况下连续调用eq(),gt()等方法它们之间是AND关系。当你需要引入OR逻辑时必须显式地调用or()方法。or()方法非常关键它表示后续条件将与前面的条件以OR连接。条件分组上面的例子中or()把整个条件分成了两部分。但有时我们需要更复杂的逻辑比如(A AND B) OR (C AND D)。这时就需要引入nested()方法进行嵌套或者使用带Consumer参数的方法如and(i - i.eq(...).gt(...))来构建子条件组。这是Wrapper进阶使用的核心后面会详细讲。链式调用的顺序就是 SQL 的顺序你写 wrapper 的顺序基本决定了最终 SQL 条件子句的顺序。这要求开发者对 SQL 逻辑有清晰的认识。实操心得在编写复杂Wrapper时我习惯先在纸上或注释里写出目标 SQL 的WHERE部分然后再转化为Wrapper代码。这能有效避免逻辑错误。另外对于超过 5 个条件的复杂查询务必使用 Lambda 版本来减少错误并多加注释说明业务逻辑。3. 核心条件构造方法深度解析Wrapper提供了数十个条件构造方法我们不可能面面俱到但必须掌握其中最核心、最容易用错的一组。3.1 等值、范围与模糊查询这是最基础也是最常用的部分。eq/ne: 等于 / 不等于。注意null值的处理eq(null)在大部分数据库驱动下会生成IS NULL但行为可能不一致最稳妥的方式是使用isNull()方法。gt/ge/lt/le: 大于 / 大于等于 / 小于 / 小于等于。常用于数字和日期比较。between/notBetween: 介于之间。参数是(column, val1, val2)注意它是闭区间[val1, val2]。like/notLike: 模糊匹配。这里有一个大坑like(“name”, “%张%”)是可以的但更推荐使用likeLeft、likeRight。likeRight(“name”, “张”): 生成name LIKE ‘张%’匹配以“张”开头。这是最常用的。likeLeft(“name”, “三”): 生成name LIKE ‘%三’匹配以“三”结尾。直接使用like时你需要自己处理百分号而likeRight/Left语义更清晰且能利用索引当使用likeRight且字段有索引时。3.2 空值处理与 IN 查询isNull/isNotNull: 专门处理NULL值。比在eq中传入null更明确。in/notIn: 集合查询。in(“role_id”, Arrays.asList(1, 2, 3))。关键技巧当传入的集合为空时MyBatis-Plus 默认会怎么处理在 3.x 版本中如果集合为空in条件会被忽略即不生效这通常会导致查询出全部数据这可能是你期望的也可能是个 bug为了安全我总是在调用in前显式判断集合是否为空if (!CollectionUtils.isEmpty(roleIds)) { wrapper.in(UserRole::getRoleId, roleIds); } else { // 根据业务决定可能是查询无结果也可能是忽略此条件 wrapper.eq(“1”, “0”); // 强制让查询无结果例如 WHERE 10 }3.3 嵌套、或逻辑与子查询进阶核心这是区分普通使用者和高阶使用者的分水岭。复杂的 AND/OR 混合逻辑 假设我们需要查询(status1 AND type IN (1,2)) OR (status2 AND create_time ‘2023-01-01’)。 错误的写法是连续调用or()那会得到错误的逻辑。正确的写法是使用nested或and/or的消费者模式// 方法一使用 nested (清晰但稍显冗长) wrapper.nested(i - i.eq(User::getStatus, 1).in(User::getType, Arrays.asList(1, 2))) .or() .nested(j - j.eq(User::getStatus, 2).gt(User::getCreateTime, LocalDate.of(2023,1,1)))); // 方法二使用 and/or 的 Consumer 参数更简洁推荐 wrapper.and(i - i.eq(User::getStatus, 1).in(User::getType, Arrays.asList(1, 2))) .or(j - j.eq(User::getStatus, 2).gt(User::getCreateTime, LocalDate.of(2023,1,1)));and(Consumer)和or(Consumer)方法会创建一个新的子Wrapper在这个子Wrapper中构建的条件会被括号包裹起来完美实现了条件分组。子查询Wrapper支持通过inSql,notInSql,exists,notExists等方法进行子查询。这功能非常强大。// 查询存在订单的用户 wrapper.exists(“SELECT 1 FROM order WHERE order.user_id user.id”); // 使用 inSql: 查询角色为“管理员”的用户 wrapper.inSql(“id”, “SELECT user_id FROM user_role WHERE role_id (SELECT id FROM role WHERE name ‘admin’)”);注意事项子查询字符串需要你自己保证正确性Wrapper不会帮你做任何转义或校验。在涉及多租户或逻辑删除时要特别注意子查询 SQL 是否会自动附加这些全局条件通常不会需要手动处理。3.4 UpdateWrapper 的 setSql 妙用UpdateWrapper除了能用set(“column”, value)设置固定值还有一个利器setSql。它允许你设置一个 SQL 片段用于执行字段的表达式更新。// 将用户的积分增加 10 UpdateWrapperUser updateWrapper new UpdateWrapper(); updateWrapper.eq(“id”, 1L) .setSql(“points points 10”); // 直接使用 SQL 表达式 // 等同于 SQL: UPDATE user SET points points 10 WHERE id 1 userMapper.update(null, updateWrapper); // 注意第一个实体参数为null这个功能在实现“原子性增减”、“更新版本号”等场景时非常有用避免了“先查询再计算最后更新”的非原子操作也减少了数据库往返次数。4. 实战结合分页、数据权限与自定义 SQL4.1 与分页插件 Page 无缝协作MyBatis-Plus 的分页插件PaginationInnerInterceptor和Wrapper是天作之合。通常我们这样用// 1. 构建分页对象 PageUser page new Page(1, 10); // 当前页每页大小 // 可以设置是否进行 count 查询优化大数据量分页性能 // page.setSearchCount(false); // 2. 构建查询条件 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getDepartmentId, 5) .orderByDesc(User::getCreateTime); // 3. 执行分页查询 PageUser resultPage userMapper.selectPage(page, wrapper); // 获取数据 ListUser records resultPage.getRecords(); long total resultPage.getTotal();这里有个性能优化点对于非常复杂的查询selectPage会自动执行两条 SQL一条COUNT(*)查询总数一条带LIMIT的分页查询数据。如果总数计算非常慢比如关联表多、条件复杂而你又不关心总条数只想要“下一页”数据可以通过page.setSearchCount(false)来禁用 count 查询提升性能。4.2 实现数据权限过滤核心实战这是Wrapper在复杂企业级应用中最闪耀的场景之一。假设我们有这样一个需求用户只能看到自己所在部门及子部门的数据。我们通常不希望在每一个查询业务代码里都手动添加这个条件而是希望通过一种全局的、无侵入的方式实现。MyBatis-Plus 提供了InnerInterceptor接口我们可以实现一个数据权限拦截器。其核心原理就是在 SQL 执行前动态地向Wrapper添加条件。Component public class DataPermissionInterceptor implements InnerInterceptor { Override public void beforeQuery(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { // 1. 判断是否需要添加数据权限例如通过注解或URI判断 if (!needDataPermission(ms)) { return; } // 2. 获取当前用户的部门ID列表从ThreadLocal或SecurityContext中 ListLong accessibleDeptIds getCurrentUserDeptIds(); // 3. 找到参数中的 QueryWrapper if (parameter instanceof Map) { Map?, ? paramMap (Map?, ?) parameter; paramMap.forEach((key, value) - { // 寻找名为‘ew’的参数这是MyBatis-Plus自动包装的Wrapper参数名 if (value instanceof QueryWrapper) { QueryWrapper? wrapper (QueryWrapper?) value; // 4. 动态添加部门过滤条件 wrapper.in(“department_id”, accessibleDeptIds); } else if (value instanceof LambdaQueryWrapper) { LambdaQueryWrapper? wrapper (LambdaQueryWrapper?) value; // 这里需要知道实体类型通用处理较复杂通常需要借助反射或约定 // 一种更通用的做法是始终使用QueryWrapper或者在特定属性上做处理 } }); } // 对于 UpdateWrapper 和 DeleteWrapper逻辑类似在 beforeUpdate/beforeDelete 中处理 } // ... 其他方法实现 }然后将这个拦截器配置到 MyBatis-Plus 的拦截器链中。这样所有相关的查询都会自动带上department_id IN (...)的条件实现了数据隔离。注意事项这种方式对直接使用mapper.selectByMap()或手写 XML 中 SQL 可能不生效需要根据情况做特殊处理或约定规范。4.3 对接 XML 中的自定义复杂 SQL有时极度复杂的查询如涉及多重嵌套子查询、特定数据库函数、优化提示仍需写在 XML 映射文件中。Wrapper同样可以与此模式协同工作。在 Mapper 接口中你可以这样定义方法// 在 UserMapper.java 中 ListUser selectUsersWithCustomCondition(Param(“ew”) QueryWrapperUser wrapper);在对应的UserMapper.xml中select id“selectUsersWithCustomCondition” resultType“User” SELECT u.*, d.name as dept_name FROM user u LEFT JOIN department d ON u.dept_id d.id -- 关键在这里使用 ${ew.customSqlSegment} ${ew.customSqlSegment} /select调用时QueryWrapperUser wrapper new QueryWrapper(); wrapper.eq(“u.status”, 1) .like(“d.name”, “研发”) .orderByDesc(“u.create_time”); ListUser list userMapper.selectUsersWithCustomCondition(wrapper);最终执行的 SQL 会是SELECT u.*, d.name as dept_name FROM user u LEFT JOIN department d ON u.dept_id d.id WHERE u.status 1 AND d.name LIKE ‘%研发%’ ORDER BY u.create_time DESC重要提示${ew.customSqlSegment}是直接拼接 SQL 片段要警惕 SQL 注入风险。但Wrapper内部在生成customSqlSegment时已经对参数进行了预编译处理使用?占位符因此通过Wrapper方法设置的条件是安全的。然而如果你手动通过wrapper.apply(“some_sql”)添加了原生 SQL 片段则需要自己确保该片段的安全性。5. 性能调优、常见陷阱与排查指南5.1 索引失效与 N1 查询问题索引失效Wrapper生成的 SQL 质量取决于你怎么用。负面案例wrapper.like(“name”, “%张三%”)如果name字段有索引前导百分号会导致索引失效。应尽量使用likeRight(“name”, “张”)。负面案例对字段进行函数操作如wrapper.apply(“DATE(create_time) ‘2023-10-01’”)这会使create_time上的索引失效。应改为范围查询wrapper.ge(“create_time”, “2023-10-01”).lt(“create_time”, “2023-10-02”)。or条件WHERE a1 OR b2如果a和b都有单列索引数据库可能不会使用索引。需要考虑使用UNION或调整查询设计。N1 查询问题这不是Wrapper独有的但在使用 MyBatis-Plus 的关联查询如TableField(existfalse)配合额外查询时容易发生。Wrapper本身不解决此问题。解决方案是使用上一节提到的自定义SQLWrapper进行 join 查询一次获取所有数据。使用 MyBatis-Plus 的TableField(select false)并手动在 Service 层做批量查询组装。考虑使用专门的关联查询插件如早期版本的join功能或第三方扩展。5.2 条件为空时的处理策略这是一个非常常见的陷阱。比如前端传回的查询参数对象很多字段是可选的。UserQueryParam param ...; // 来自前端的参数 LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); if (StringUtils.isNotBlank(param.getName())) { wrapper.like(User::getName, param.getName()); } if (param.getStatus() ! null) { wrapper.eq(User::getStatus, param.getStatus()); } // ... 更多条件如果所有条件都为空wrapper就是一个“空”条件最终 SQL 会是SELECT * FROM user这可能返回海量数据引发性能问题。必须增加一个兜底策略添加一个永假条件不推荐影响可读性wrapper.eq(“1”, “0”)。在业务层进行判断如果所有条件为空则直接返回空列表或抛出参数异常。强制要求分页即使条件为空也必须有分页参数限制结果集大小最推荐。5.3 日志排查与 SQL 调试MyBatis-Plus 默认配置下执行的 SQL 会打印到日志。但有时我们需要更清晰地看到Wrapper最终生成的 SQL 片段和参数。开启完整 SQL 日志在application.yml中配置mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 控制台打印完整SQL带?占位符或者使用p6spy等第三方组件可以打印出替换参数后的真实 SQL。直接获取 SQL 片段在调试代码时你可以直接调用wrapper.getCustomSqlSegment()和wrapper.getParamNameValuePairs()来查看Wrapper生成的 WHERE 条件片段和参数映射这有助于理解复杂条件组合后的结果。常见错误对照表现象可能原因解决方案查询结果与预期不符and()/or()逻辑嵌套错误使用nested()或and(Consumer)/or(Consumer)明确分组更新了所有记录UpdateWrapper没有设置where条件务必在更新前确认wrapper包含了有效的where条件参数绑定异常Lambda 表达式引用错误如引用非 getter 方法确保使用正确的实体类属性和方法引用性能突然变慢生成了导致索引失效的 SQL如LIKE ‘%xx’检查Wrapper条件使用EXPLAIN分析 SQL分页总数查询慢关联表多或条件复杂考虑page.setSearchCount(false)或优化 count 语句5.4 自定义全局条件处理除了数据权限Wrapper还可以方便地处理一些全局逻辑比如逻辑删除和多租户。MyBatis-Plus 内置了这些功能的拦截器。以逻辑删除为例你只需要在实体字段上加TableLogic并在配置中开启逻辑删除。之后你所有的delete操作都会变为update set deleted1所有的select操作都会自动加上AND deleted0条件。这个自动添加的条件就是通过Wrapper的机制在底层实现的。理解这一点有助于你在需要“忽略逻辑删除条件”进行查询时如管理后台知道如何使用wrapper.ignoreLogicDelete()等方法。
