MyBatisPlus自定义SQL

目录

一、自定义SQL介绍

二、自定义SQL的原因

1.案例

（1）不使用自定义SQL

（2）使用自定义SQL

三、总结

---

一、自定义SQL介绍

我们可以利用MyBatisPlus的Wrapper来构建复杂的where条件，然后自己定义SQL语句中的剩下的部分。

进一步解释：我们使用MybatisPlus来完成SQL语句的where条件构造，然后再自己写剩下的SQL语句。两者结合在一起共同完成整个SQL语句的构建。

二、自定义SQL的原因

为什么要自定义SQL?直接用MybatisPlus完成全部SQL语句的构造好像也是可以的。

这里我将通过一个案例进一步解释

案例前提：

• 数据库中有一张user表，并且已经创建了User实体类。
• userMapper继承了BaseMapper接口

1.案例

需求：将id在指定范围的用户（例如1、2、4）的余额扣减指定值

（1）不使用自定义SQL

如果我们不使用自定义SQL,完全通过MybatisPlus来构造SQL语句，则如图所示：

似乎也能完成需求，但是存在一个问题，当前写的部分是业务逻辑，将来是在service中定义的，这就相当于我们把sql语句的一部分（图中红色方框标记的位置）写在了业务当中。这在很多企业的开发规范中是不允许的。要求只能在mapper层和mapper.xml当中去定义SQL语句，所以这种写法不行。

（2）使用自定义SQL

如果我们使用自定义SQL。

首先基于Wrapper构建where条件

这里ids和amount假设是从前端得到的数据，updateBalanceByIds是我们自定义的mapper方法，如下图：

在mapper方法参数中用Param注解声明wrapper变量名称时，必须为ew。而其他变量的Param声明可以按照业务自定义。

最后在xml文件中自定义SQL，并使用Wrapper条件：

红色部分是自定义SQL，蓝色部分是通过${ew.customSqlSegment}使用Wrapper条件。

测试结果：

成功进行了更新。

三、总结

当我们直接使用MybatisPlus来构造sql语句时，如果发现where条件以外的部分需要直接写sql语句，如图

sql语句直接写在了业务逻辑中，不符合企业开发规范，需要我们使用MybatisPlus的自定义SQL方式来构造SQL语句，即：我们使用MybatisPlus来完成SQL语句的where条件构造，然后再自己写剩下的SQL语句。两者结合在一起共同完成整个SQL语句的构建。