目录
1.@TableName
我们在使用MyBatis-Plus实现基本的CRUD时，我们并没有指定要操作的表，只是在 Mapper接口继承BaseMapper时，设置了泛型User，而操作的表为user表 所以MyBatis-Plus在确定操作的表时，由BaseMapper的泛型决定，即实体类型决定，且默认操作的表名和实体类型的类名一致
如果我们的实体类类名和我们要操作的表面不一致会发生什么？
我们把数据库表名字改一下：
改完后运行测试方法：
我们看到数据库的报错说user表不存在，所以MybatisPlus操作的是我们指定的User类
如果遇到这种情况，我们可以用@TableName注解解决
我们在实体类User的上面添加注解@TableName("t_user")
再重新运行刚才的测试方法：
运行就成功了。
@TableName注解可以用来解决实体类和数据库表名称不匹配的问题。
我们也可以通过配置全局来解决这个问题：
把User实体类上面的@TableName注解去掉，随后在yaml配置文件中配置统一前缀
2.@TableId
@TableId主要有两个作用：
(1)解决数据库id和实体类id名称不匹配的问题
(2)决定id生成策略
(1)解决数据库id和实体类id名称不匹配的问题
假如我们实体类的id命名和数据库中的并不一致，我们可以在实体类当中的id声明上一行写上数据库id，假如数据库id名称是uid，实体类里面的id名称是id：
我们直接运行测试方法的话：
此时mybatisplus找不到主键名称
我们在实体类这里加上：
再运行：
问题就解决了
(2)决定id生成策略
@TableName可以携带两个参数，一个是value，解决id匹配的问题，一个是type，决定id的生成策略。
我们比较常用的id生成策略有两种：雪花算法ASSIGN_ID和数据库id自增AUTO
在使用自增的时候要保证数据库当中的自动递增是打开的，否则会报错：
雪花算法：
雪花算法是由Twitter公布的分布式主键生成算法，它能够保证不同表的主键的不重复性，以及相同表的 主键的有序性。
①核心思想：
长度共64bit（一个long型）。
首先是一个符号位， 1bit标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0。
41bit时间截(毫秒级)，存储的是时间截的差值（当前时间截 - 开始时间截)，结果约等于69.73年。
10bit作为机器的ID（ 5个bit是数据中心， 5个bit的机器ID，可以部署在1024个节点）。
12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID）。
②优点：整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞，并且效率较高。
3.@TableField
经过以上的测试，我们可以发现， MyBatis-Plus在执行SQL语句时，要保证实体类中的属性名和 表中的字段名一致。
如果实体类中的属性名和字段名不一致的情况，会出现什么问题呢？
(1)若实体类中的属性使用的是驼峰命名风格，而表中的字段使用的是下划线命名风格
例如实体类属性userName，表中字段user_name
此时MyBatis-Plus会自动将下划线命名风格转化为驼峰命名风格
(2)若实体类中的属性和表中的字段不满足情况(1)
例如实体类属性name ，表中字段username
此时需要在实体类属性上使用@TableField("username")设置属性所对应的字段名
第二类情况和上面的id和table名字是一样的，就不再赘述。
4.@TableLogic
物理删除：真实删除，将对应数据从数据库中删除，之后查询不到此条被删除的数据
逻辑删除：假删除，将对应数据中代表是否被删除字段的状态修改为"被删除状态"，之后在数据库
中仍旧能看到此条数据记录
使用场景：可以进行数据恢复
实现逻辑删除：
数据库中创建逻辑删除状态列，设置默认值为0
然后在实体类中添加逻辑删除
最后测试：
我们可以看到它实际上执行的是update方法，把id为23的记录的is_deleted字段更新成了1
