lambdaQueryWrapper自定义sql

MP自带的条件构造器虽然很强大，有时候也避免不了写稍微复杂一点业务的sql，比如多表查询。

那么那么今天说说MP怎么自定义sql语句吧。另外,除了下文提到的通过queryWrapper实现筛选以外,调用查询时,如果你需要做分页,通过mybatisPlus提供的分页接口IPage,能够避免自己手写分页的sql语句,这么好用的东西,你还不入坑吗?

总结：QueryWrapper是Wrapper下面的类。 -->完全可以用到多态；令QueryWrapper实例指向Wrapper对象。 记住：多态，参数类型是Wrapper类型，调用者传递QueryWrapper类型。

因为官方文档里面写的参数类型都是父级类型，不要再说看不懂官方文档。

需求来源:

在使用了mybatis-plus之后, 自定义SQL的同时也想使用Wrapper的便利应该怎么办？ 在mybatis-plus版本3.0.7得到了完美解决 版本需要大于或等于3.0.7, 以下两种方案取其一即可

mybatisPlus的条件构造器进行简单的操作还行，但是我的复杂操作如多表查询，条件构造器就显得捉襟见肘了。

还有一个更重要的原因：我想用他的分页插件。 如果我使用mybatis写法就不能使用mybatisPlus的分页插件了。

${ew.sqlSegment} 是补充条件的—QueryWrapper的条件构造器的条件。

官方文档写的有点笼统，现在我们看看网友的详细写法：

Mybatis-plus中自定义的sql语句调用QueryWrapper实现查询

这个只是讲述了自定义sql，没有涉及自定义sql和分页一起的使用。

网址案例通过测试是成功的。

但这往往不够，实际我们会使用更多复杂的sql语句。会往自定义sql语句里面传递值，会需要分页。

[MyBatis-Plus 分页查询以及自定义sql分页(很好的文档)]

这是三大技术点整合，看见分页技术就知道结果一定是返回分页的数据的。

当然，如果是自定义SQL和条件构造器两个技术整合，我们返回的是集合。

记住：分页不过也是limit语句，也是sql语句罢了，不要想太神。

注意：这个条件构造器与两外两个技术整合一起使用的前提有点苛刻，要求返回数据model格式必须是和这个表的字段对应，然后在表明的后面帮我们添加一系列条件。–${ew.sqlSegment} 是补充条件的，他的位置决定你的条件构造器的条件加到哪里。

但是，可能有时候我们的sql语句过于复杂，在多表查询的时候需要你传递一个参数或几个参数。放心，条件构造器该用就用，判断好位置就行；这几个参数该传就传，和mybatis操作一样。

controller

mapper.java

mapper.xml

${ew.customSqlSegment}的位置决定了条件构造器的条件在哪。