【Plus】五、常用注解

点击访问官网 注解！

1、@TableName

• 描述：表名注解，标识实体类对应的表
• 使用位置：实体类

@TableName("sys_user")
public class User {
    // ...
}

属性	类型	必须指定	默认值	描述
value	String	否	“”	表名
schema	String	否	“”	schema
keepGlobalPrefix	boolean	否	false	是否保持使用全局的 tablePrefix 的值 （当全局 tablePrefix 生效时）
resultMap	String	否	“”	xml 中 resultMap 的 id （用于满足特定类型的实体类对象绑定）
autoResultMap	boolean	否	false	是否自动构建 resultMap 并使用 （如果设置 resultMap 则不会进行 resultMap 的自动构建与注入）
excludeProperty	String[]	否	{}	需要排除的属性名 @since 3.3.1

如果是所有表都有一个固定的前缀，也可使用全局配置

mybatis-plus: 
	global-config: 
		db-config: 
            # 配置MyBatis-Plus操作表的默认前缀
            table-prefix: t_

如此就不需要在每个实体类上通过@TableName标识实体类对应的表

2、@TableId

• 描述：主键注解
• 使用位置：实体类主键字段

@TableName("sys_user")
public class User {
    @TableId
    private Long id;
    // ...
}

属性	类型	必须指定	默认值	描述
value	String	否	“”	主键字段名
type	Enum	否	IdType.NONE	指定主键类型

IdType：

值	描述
AUTO	数据库 ID 自增(数据库必须设置自增不然报错)
NONE	无状态，该类型为未设置主键类型（注解里等于跟随全局，全局里约等于 INPUT）
INPUT	insert 前自行 set 主键值
ASSIGN_ID	分配 ID(主键类型为 Number(Long 和 Integer)或 String)(@Since 3.3.0),使用接口IdentifierGenerator的方法nextId(默认实现类为DefaultIdentifierGenerator雪花算法)
ASSIGN_UUID	分配 UUID,主键类型为 String(@Since 3.3.0),使用接口IdentifierGenerator的方法nextUUID(默认 default 方法)
D_WORKER	分布式全局唯一 ID 长整型类型(please use ASSIGN_ID)
UUID	32 位 UUID 字符串(please use ASSIGN_UUID)
ID_WORKER_STR	分布式全局唯一 ID 字符串类型(please use ASSIGN_ID)

想要使用统一的主键生成策略，也可使用全局配置

mybatis-plus: 
	global-config: 
		db-config: 
            # 配置MyBatis-Plus的主键策略
            id-type: auto

如此就不需要在每个实体类里通过@TableId的 type来指定主键生成策略了

点击深入了解 雪花算法

3、@TableField

• 描述：字段注解（非主键）

@TableName("sys_user")
public class User {
    @TableId
    private Long id;
    @TableField("user_name")
    private String name;
    // ...
}

属性	类型	必须指定	默认值	描述
value	String	否	“”	数据库字段名
exist	boolean	否	true	是否为数据库表字段
condition	String	否	“”	字段 where 实体查询比较条件，有值设置则按设置的值为准，没有则为默认全局的 %s=#{%s}，参考
update	String	否	“”	字段 update set 部分注入，例如：当在version字段上注解update="%s+1" 表示更新时会 set version=version+1 （该属性优先级高于 el 属性）
insertStrategy	Enum	否	FieldStrategy.DEFAULT	举例：NOT_NULL insert into table_a(<if test="columnProperty != null">column</if>) values (<if test="columnProperty != null">#{columnProperty}</if>)
updateStrategy	Enum	否	FieldStrategy.DEFAULT	举例：IGNORED update table_a set column=#{columnProperty}
whereStrategy	Enum	否	FieldStrategy.DEFAULT	举例：NOT_EMPTY where <if test="columnProperty != null and columnProperty!=''">column=#{columnProperty}</if>
fill	Enum	否	FieldFill.DEFAULT	字段自动填充策略
select	boolean	否	true	是否进行 select 查询
keepGlobalFormat	boolean	否	false	是否保持使用全局的 format 进行处理
jdbcType	JdbcType	否	JdbcType.UNDEFINED	JDBC 类型 (该默认值不代表会按照该值生效)
typeHandler	Class<? extends TypeHandler>	否	UnknownTypeHandler.class	类型处理器 (该默认值不代表会按照该值生效)
numericScale	String	否	“”	指定小数点后保留的位数

关于jdbcType和typeHandler以及numericScale的说明:

numericScale只生效于 update 的 sql. jdbcType和typeHandler如果不配合@TableName#autoResultMap = true一起使用,也只生效于 update 的 sql. 对于typeHandler如果你的字段类型和 set 进去的类型为equals关系,则只需要让你的typeHandler让 Mybatis 加载到即可,不需要使用注解

FieldStrategy

值	描述
IGNORED	忽略判断
NOT_NULL	非 NULL 判断
NOT_EMPTY	非空判断(只对字符串类型字段,其他类型字段依然为非 NULL 判断)
DEFAULT	追随全局配置
NEVER	不加入SQL

FieldFill

值	描述
DEFAULT	默认不处理
INSERT	插入时填充字段
UPDATE	更新时填充字段
INSERT_UPDATE	插入和更新时填充字段

4、@Version

• 描述：乐观锁注解、标记 @Verison 在字段上

具体使用请参考MyBatis-Plus官网 乐观锁插件
也可参考小白个人笔记 七、插件（2、乐观锁）

5、@EnumValue

• 描述：普通枚举类注解(注解在枚举字段上)

具体使用请参考MyBatis-Plus官网 通用枚举
也可参考小白个人笔记 八、通用枚举

6、@TableLogic

• 描述：表字段逻辑处理注解（逻辑删除）

属性	类型	必须指定	默认值	描述
value	String	否	“”	逻辑未删除值
delval	String	否	“”	逻辑删除值

具体使用请参考MyBatis-Plus官网 逻辑删除

7、@SqlParser

see @InterceptorIgnore

8、@KeySequence

• 描述：序列主键策略 oracle
• 属性：value、resultMap

属性	类型	必须指定	默认值	描述
value	String	否	“”	序列名
clazz	Class	否	Long.class	id 的类型, 可以指定 String.class，这样返回的 Sequence 值是字符串"1"

9、@InterceptorIgnore

see 插件主体

10、@OrderBy

• 描述：内置 SQL 默认指定排序，优先级低于 wrapper 条件查询

属性	类型	必须指定	默认值	描述
isDesc	boolean	否	true	是否倒序查询
sort	short	否	Short.MAX_VALUE	数字越小越靠前

---

正文到此为止！下面是介绍雪花算法的内容。

---

雪花算法

---

• 背景

需要选择合适的方案去应对数据规模的增长，以应对逐渐增长的访问压力和数据量。

数据库的扩展方式主要包括：业务分库、主从复制，数据库分表。

• 数据库分表

将不同业务数据分散存储到不同的数据库服务器，能够支撑百万甚至千万用户规模的业务，但如果业务 继续发展，同一业务的单表数据也会达到单台数据库服务器的处理瓶颈。例如，淘宝的几亿用户数据， 如果全部存放在一台数据库服务器的一张表中，肯定是无法满足性能要求的，此时就需要对单表数据进 行拆分。

单表数据拆分有两种方式：垂直分表和水平分表。示意图如下：

• 垂直分表

垂直分表适合将表中某些不常用且占了大量空间的列拆分出去。

例如，前面示意图中的 nickname 和 description 字段，假设我们是一个婚恋网站，用户在筛选其他用 户的时候，主要是用 age 和 sex 两个字段进行查询，而 nickname 和 description 两个字段主要用于展 示，一般不会在业务查询中用到。description 本身又比较长，因此我们可以将这两个字段独立到另外 一张表中，这样在查询 age 和 sex 时，就能带来一定的性能提升。

• 水平分表

水平分表适合表行数特别大的表，有的公司要求单表行数超过 5000 万就必须进行分表，这个数字可以 作为参考，但并不是绝对标准，关键还是要看表的访问性能。对于一些比较复杂的表，可能超过 1000 万就要分表了；而对于一些简单的表，即使存储数据超过 1 亿行，也可以不分表。

但不管怎样，当看到表的数据量达到千万级别时，作为架构师就要警觉起来，因为这很可能是架构的性 能瓶颈或者隐患。

水平分表相比垂直分表，会引入更多的复杂性，例如要求全局唯一的数据id该如何处理？

主键自增

1. 以最常见的用户 ID 为例，可以按照 1000000 的范围大小进行分段，1 ~ 999999 放到表 1中， 1000000 ~ 1999999 放到表2中，以此类推
2. 复杂点：分段大小的选取。分段太小会导致切分后子表数量过多，增加维护复杂度；分段太大可能会 导致单表依然存在性能问题，一般建议分段大小在 100 万至 2000 万之间，具体需要根据业务选取合适 的分段大小
3. 优点：可以随着数据的增加平滑地扩充新的表。例如，现在的用户是 100 万，如果增加到 1000 万， 只需要增加新的表就可以了，原有的数据不需要动
4. 缺点：分布不均匀。假如按照 1000 万来进行分表，有可能某个分段实际存储的数据量只有 1 条，而 另外一个分段实际存储的数据量有 1000 万条

取模

1. 同样以用户 ID 为例，假如我们一开始就规划了 10 个数据库表，可以简单地用 user_id % 10 的值来 表示数据所属的数据库表编号，ID 为 985 的用户放到编号为 5 的子表中，ID 为 10086 的用户放到编号 为 6 的子表中
2. 复杂点：初始表数量的确定。表数量太多维护比较麻烦，表数量太少又可能导致单表性能存在问题
3. 优点：表分布比较均匀
4. 缺点：扩充新的表很麻烦，所有数据都要重分布

雪花算法

雪花算法是由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碰撞，并且效率较高。