乐悠厨房1. QueryWrapper.apply方法的核心作用
QueryWrapper是MyBatis-Plus框架中用于构建SQL查询条件的核心工具类，而apply方法则是其中最强大但也最容易用错的动态SQL构建方法之一。简单来说，apply允许你在WHERE子句中直接插入任意SQL片段，相当于一个"万能钥匙"。
这个方法的设计初衷是为了处理那些无法通过常规条件构造方法（如eq、like等）表达的复杂查询场景。比如需要调用数据库函数、使用特殊运算符或实现子查询时，apply就派上用场了。它的方法签名是这样的：
java复制Children apply(String applySql, Object... params)
第一个参数是SQL片段，可以包含占位符{}或#{}；第二个参数是可变参数，用于替换占位符。这里有个关键点：MyBatis-Plus会对这些参数进行预编译处理，防止SQL注入。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. apply方法的典型使用场景
2.1 数据库函数调用
假设我们需要查询注册时间超过30天的用户，常规方法无法直接表达这种日期计算：
java复制queryWrapper.apply("DATEDIFF(NOW(), create_time) > 30");
这个例子中，我们直接调用了MySQL的DATEDIFF函数。生成的SQL会是：
sql复制WHERE DATEDIFF(NOW(), create_time) > 30
2.2 复杂条件表达式
当需要组合多个条件形成一个复杂表达式时，apply特别有用。比如查询价格在特定范围内或者折扣率高于某个值的商品：
java复制queryWrapper.apply("(price BETWEEN {0} AND {1}) OR (discount > {2})",
minPrice, maxPrice, minDiscount);
2.3 子查询场景
apply最常见的用途之一就是构建子查询。例如查找没有订单的用户：
java复制queryWrapper.apply("NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = user.id)");
3. apply与其它方法的对比
3.1 与常规条件构造方法的区别
MyBatis-Plus提供了一系列条件构造方法如eq、ne、gt等，这些方法都是类型安全的，编译器会检查参数类型。而apply则是"万能"但"不安全"的，它接收的是字符串，编译器无法检查SQL语法是否正确。
3.2 与SQL注入式方法的区别
MyBatis-Plus还有last方法可以直接拼接SQL，但这是极其危险的，因为不会做参数预编译。例如：
java复制// 危险！会导致SQL注入
queryWrapper.last("AND name = '" + name + "'");
// 安全！参数会被预编译
queryWrapper.apply("AND name = {0}", name);
4. apply方法的高级用法
4.1 动态表名查询
在一些分表场景下，表名需要动态确定。比如按年份分表查询：
java复制String tableName = "orders_" + year;
queryWrapper.apply("EXISTS (SELECT 1 FROM " + tableName + " WHERE " + tableName + ".user_id = user.id)");
注意：虽然这种用法可行，但在分表场景下更推荐使用MyBatis-Plus的动态表名插件。
4.2 条件注解结合使用
apply可以与@Select注解结合使用，实现更复杂的查询：
java复制@Select("SELECT * FROM user ${ew.customSqlSegment}")
List<User> selectAll(@Param(Constants.WRAPPER) QueryWrapper<User> wrapper);
然后在Service层可以这样构建查询：
java复制queryWrapper.apply("id IN (SELECT user_id FROM vip_user WHERE level > {0})", minLevel);
5. apply方法的性能考量
虽然apply很强大，但过度使用会影响性能：
-
索引失效风险：apply中的复杂表达式可能导致索引失效。例如
apply("YEAR(create_time) = 2023")会使create_time上的索引失效，而应该用between。 -
SQL解析开销：MyBatis需要解析这些动态SQL片段，比预编译的静态SQL开销大。
-
数据库兼容性：不同数据库的函数和语法可能有差异，使用apply会降低SQL的可移植性。
6. 实际项目中的最佳实践
6.1 参数化所有变量
永远不要直接拼接用户输入到apply中：
java复制// 错误示范（SQL注入风险）
queryWrapper.apply("name = '" + name + "'");
// 正确做法
queryWrapper.apply("name = {0}", name);
6.2 限制apply的使用范围
只在以下场景使用apply：
- 需要调用数据库特定函数时
- 需要实现复杂子查询时
- 其他条件构造方法无法满足需求时
6.3 统一管理复杂SQL片段
对于频繁使用的复杂apply片段，建议集中管理：
java复制public class SqlTemplates {
public static String VIP_USER_SUBQUERY =
"EXISTS (SELECT 1 FROM vip_user WHERE vip_user.user_id = {0} AND vip_user.level >= {1})";
}
// 使用
queryWrapper.apply(SqlTemplates.VIP_USER_SUBQUERY, "user.id", minLevel);
7. 常见问题排查
7.1 参数占位符混淆
MyBatis-Plus支持两种占位符：
{}：直接替换，有SQL注入风险#{}：预编译处理，安全
建议始终使用#{}：
java复制// 安全
queryWrapper.apply("name = #{0}", name);
// 不安全（特殊场景下可能有风险）
queryWrapper.apply("name = {0}", name);
7.2 多表查询时的列名冲突
在多表关联查询时，注意列名的明确指定：
java复制// 可能导致歧义
queryWrapper.apply("status = 1");
// 明确指定表名
queryWrapper.apply("user.status = 1");
7.3 日期时间处理的陷阱
不同数据库的日期函数差异很大：
java复制// MySQL
queryWrapper.apply("DATE(create_time) = '2023-01-01'");
// Oracle
queryWrapper.apply("TRUNC(create_time) = TO_DATE('2023-01-01', 'YYYY-MM-DD')");
8. 替代方案探讨
在某些场景下，可以考虑以下替代方案：
-
自定义SQL：对于特别复杂的查询，直接在XML或注解中写完整SQL可能更清晰。
-
Lambda表达式：MyBatis-Plus 3.0+支持Lambda形式的条件构造，更类型安全：
java复制queryWrapper.lambda().eq(User::getName, name);
- SQL构建器：对于极度复杂的动态SQL，可以考虑使用MyBatis Dynamic SQL等专门工具。
9. 源码解析
了解apply的实现原理有助于更好地使用它。在QueryWrapper中，apply方法最终会将SQL片段添加到WHERE条件中：
java复制public Children apply(String applySql, Object... params) {
sql.APPLY(applySql, params);
return typedThis;
}
其中sql是AbstractWrapper的内部类SqlSegmentBuilder的实例，APPLY方法会将SQL片段和参数存储起来，最终在getSqlSegment方法中拼接成完整的WHERE子句。
10. 版本兼容性说明
不同版本的MyBatis-Plus中apply方法的行为可能有细微差别：
- 3.0以下版本：参数替换逻辑较为简单
- 3.0-3.4版本：增强了SQL注入防护
- 3.5+版本：支持Lambda形式的apply
在使用时应当注意项目使用的MyBatis-Plus版本，特别是升级时要注意测试相关功能。