mybatisPlus常用注解

@TableName(value = “正真得表名”)
这个注解加到实体类上 , 用于指定他与那个表做映射

@TabelId(type = “IdType.ASSIGN_ID”)
这个注解是加在实体类中主键字段上的 , ASSIGN_ID就是雪花算法。

@TableId
这个注解是 标识一个字段为主键的注解 , 用于实体类中的主键字段上 , 在主键字段上添加这个注解 , mybatisplus就会将这个字段识别为主键 , 并且在执行sql时就会为这个主键采用自动生成策略生成主键值添加到数据库中

@TableId(value = “uid”)
private Long id;
这个注解做的是数据库中主键列叫uid , 但是我们的实体类中字段名叫id , 我们通过这个注解的value属性设置为uid , 让这个字段与数据库中的uid列进行匹配

@TableField(value = “username”)
private String name;
这个是用于普通的字段的映射关系声名注解

@TableField(fill = FiledFill.INSERT等枚举)
做自动填充用的

@TableLogic
逻辑删除字段
数据库字段一般叫做is_deleted 是tinyint做boolean值
实体类中一般起名为deleted

  1. 垂直分表:
    通常我们企业级项目会有巨大的高并发访问
    为了提升我们的数据库承载能力 ,我们通常会将常用于查询的字段和字段值特别长的字段分成两张表。我们看一个列子

比如我们有一个表叫做user表 , 这user表中我们有 id , sex, age , nickname , description

我们通常会把nickname和description两字段分在另外一张表,我i们会将表结构分为如下:
user : id , sex , age
user_info:nickname , description
我们为什么要这么分呢
因为id , age , sex通常会常用于查询条件 , 而nickname和description通常用于展示 , 并且description一般可能会有几千字几万字的描述 , 字段值非常大 , 当数据量很大的时候我们执行这样的分表策略会提高我们的查询效率。

我们的user和userinfo两张表是一对一的关系 , 所以user表的id和user_info表的id一致。

  1. 水平分表:

第一种方案 , 就是主键自增长 , 就是类似下图 , 我们给一张表加满了然后紧接着给下一张表接着加 , 但是这样的话就会有很大的缺陷 , 就是假如第一张表的中间数据被删掉了 , 我们还是一直往后边加表追加 ,那就会导致这几张表数据量严重不均衡 , 并且 就算不删前边表的中间数据 , 后边表数据量刚开始会很少 , 而访问还是非常不均衡 , 会导致第一张表访问量特别大 , 第二张表却闲着 。 这种方法有一个有点就是扩展方便。

这里的分表 ,多个表一般不会在一台服务器上
在这里插入图片描述
第二种方案:
如下图 , 这种方案 , 我们可以第一张表是1 , 第二章表是2 , 第三张表是3开始 , 然后步长让他们为3 , 这样就可以做到均衡了 , 但是这样会出现扩展不方便的问题
在这里插入图片描述
我们可以使用随机生成的hash来进行主键的设置 , 这样的话只要保证主键唯一就可以 , 这样的话以上因为自增导致的那些问题就可以解决了 ,但是这样的随机hash又会有新的问题 , 就是他无法使用mysql中的聚簇索引 , 简单来说就是因为主键没了顺序会导致查询效率变低 , 那怎么办呢?

接下来就是看雪花算法 , 这个算法可以解决以上的所有问题
在这里插入图片描述

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值