快捷键：ctrl + f12查看当前类的所有方法。
快捷键：双击Shift，全局搜索类名
首先，这个mybatis-plus只是对于我们使用mybatis的基础上进行的一种增强，我们前面写mybatis相关的增删改查操作，是不是要写接口，还要自己在xml写sql语句，当然这是xml写法比较复杂，我没说那个只在接口上面写sql语句的那种写法，反正我感觉下来，尤其是那种动态sql语句，写起来比较麻烦，所以我们的mybatis-plus就是为了简化我们写各种复杂sql语句的一种简化，它呢，化繁为简，是真的香！
目录
🍁创建项目
我们前面写mybatis都加了MyBatis Framework依赖，为啥这次写mybatis-plus不加呢，因为道理很简单，mybatis-plus已经把MyBatis Framework给"集成"了，就是它里面有它的意思。
但是呢，添加mybatis-plus依赖需要看我们的spring boot版本，我的spring boot版本是spring boot4，我们观察一下xml文件里的spring boot版本，
这个写的是以4.0.6，这个以4开头的表示大版本。
🍀然后添加对应的版本的mybatis-plus依赖
配置相关的数据库相关的配置
这个不用多说，毕竟要告诉mybatis-plus要咋连接数据库，连接哪个，密码是多少，jdbc的驱动等。
配置打印信息
🍀接口
我们如果用这个mybatis-plus，需要在接口上继承BaseMapper
观察basemapper接口发现，
再观察basemapper的父类mapper接口
发现只有basemapper接口里写了许多方法壳子，方法里面的逻辑啥也没写，那我就也不等到演示的时候讲了，其实不是basemapper接口自带的，只是它里面规定了很多的方法壳子，没有去写具体的代码逻辑，最后还是mybatis-plus根据你调用了哪个方法壳子，去生成对应的代码。我不知道我的理解正确不，但我要表述的就是这个意思。
🍀测试
这个写法是不是和前面博客聊的mybatis写法差不多，唯独方法有没有实现的区别。
还有就是，我们没有告诉mybatis-plus操作哪张表，它是怎么知道的呢，其实我们在写接口的时候，不是继承了一个basemapper<>嘛里面填的参数虽然是个实体类，但mybatis-plus会自动进行驼峰自动转化操作，以次来确定操作的是哪张表！
可是我们发现这个id它有点不正常，太大了，而且没有在id为15后面自增为16，大家是不是很疑问？
这是因为mybatis-plus对于自增主键的id在没设值的情况下，采用了雪花算法，帮我们生成了一个id。大家感兴趣可以去搜搜，好像说啥为了啥安全，我不感兴趣哈哈，随意。
所以咋样解决呢，大家不要一上来就说要这样一步到位，因为不断的探索解决问题，尝试，本生就是个自我提升的过程，我们不应该急于求成，说实话，我自己也浮躁，但我能做的就是让自己不那么浮躁，虽然我也很菜吧。
然后我们在id这个加上这个注解，试试，先试试，后讲原理！--这块我被搞的太难受了哈
测试用例还是上面的哈，我就不再写了
但是吧，这有个问题就是，我不希望这个新插入的数据这么离谱，我希望的是它能够跟在id为15的后面，所以我们咋解决呢？
我们就需要在navicat上把这个对应表的选项这块的主键自动递增设置好
当然如果还不行的话，就把表删了，重新建吧哈哈。
可是我们发现，还有很多增删改查的参数里有Wrapper这个类型，那这个是啥呢，咋用呢？
还有点就是，@Mapper注解我们放在接口上，如果不写呢，那我们就需要在spring启动类上加个@MapperScan（接口的路径）即可，这里不演示。
还有就是我们的yml文件里没配置驼峰自动转化，那为啥会成功呢，因为mybatis-plus会帮我们进行驼峰自动转化！
当然，如果我们硬是把实体类没按驼峰自动转化的规则来，也可以通过@TableName来进行映射。
但如果说，我们的属性名也没按照驼峰自动转化的规则来，可以通过@TableField注解搞定映射关系。
如果说，你创建表和实体类的时候，那个表里面的id自增主键名字和实体类的id名字无法通过驼峰自动转化来映射上，这时候你就在实体类的上面加个@TableId注解，它里面有value参数-id映射的值，type参数--雪花算法自动生成id值。
当然如果你只写了@TableName注解，而value和type参数都没写，那么，它将默认使用雪花算法，并对你的字段id进行驼峰自动转化。
🍁条件构造器
上面我们知道，方法参数类型有好多wrapper，接下来我们学习下wrapper
而我们下面讲的这4个构造器呢，又继承了AbstractWrapper
AbstractWrapper的方法很多
比如eq啊like啊，是吧，下面4个构造器就可以不只局限与自己特有的方法嘛。都可以用嘛。
🍀QueryWrapper
用于构造查询条件
先构造wrapper，再传参
这里的select表示，要查询的列，然后eq是where子句里的查询条件，like是模糊查询，上面的a就表示模糊查询%a%这样子，最后wrapper子句构造完毕，再通过userInfoMapper的selectList方法调用，里面接收的是一个wrapper。
那是不是我们的这个QueryWrapper只能说是用于构造一个查询条件的查询语句啊，不是的，只要有where的身影，大部分情况下都可以使用这个QueryWrapper的，例如：
我们要更新age小于19的所有数据行，把它的delete_flag字段设为1。
首先我解释下上面这个代码，QueryWrapper构造where条件，userinfo对象构造set更新的语句，最后由我们的继承了basemapper的userInfoMapper接口来调用mybatis-plus的update的一对象一wrapper的方法，最后更新成功
难道只可以查和改嘛，删也可以嘛，如下
是吧，方法很多嘛，我们不用去记方法，去用嘛，自然就知道了，用起来还是很清晰嘛。
小总结：QueryWrapper就是有个特殊的select方法，用于查询的指定列名！！
🍀UpdateWrapper
用于构造更新条件
这里的set方法是UpdateWrapper构造器特有的，in和update是父类AbstractWrapper的。
这里就是如果在gender字段在1，2范围内的，就更新delete_flag字段为0.够清楚了吧哈哈。
还可以这样
setsql方法，也是这个UpdateWrappe构造器特有的，这个我大家看代码就懂的，我就不想写了哈哈
🍀LamedaQueryWrapper
lambda这种写法，其目的就是为了解决写错字段名时编译不报错的问题，也就是lambda写法是会在编译阶段就检查的写法。
下面这两个是相同的含义，是"等价的！"
java
QueryWrapper<UserInfo> queryWrapper=new QueryWrapper<>();
queryWrapper.lambda()
java
LambdaQueryWrapper<UserInfo> queryWrapper=new LambdaQueryWrapper<>();结果
🍀LamedaUpdateWrapper
这个也和上面一样，不多说了。
为啥叫lambda写法呢，
也就是说，我们写的LamedaQueryWrapper也好LamedaUpdateWrapper也罢，不是真正意义上的lambda写法，只是相似而已。大家不要误会哈哈。
🍁自定义sql
🍀一般写法
接口
我画红框框的呢是固定写法，大家可以去mybatis-plus的官网看看，我就不想说了，如下
测试
结果
所以还是我们前面说的QueryWrapper它是构造查询where子句的，实不是get到了这个意思哈哈。
Wrapper与QueryWrapper的关系
继承继承继承，java就是喜欢继承这个继承哪个，实现也是，无语了都。
🍀当然我们也可以用xml的方式
接口
上面就不要跟sql语句了
对应的xml
测试
查询成功
我本人不是很喜欢这种xml写法，我觉得难受哈。
🍀混用写法
接口
测试
结果
完结，爽。