Mybatis_Plus中的常用注解

1、@TableName

@TableId

@TableId的type屬性

@TableField?

1、@TableName

經過以上的測試，在使用MyBatis-Plus實現基本的CRUD時，我們并沒有指定要操作的表，只是在 Mapper接口繼承BaseMapper時，設置了泛型User，而操作的表為user表

由此得出結論，? MyBatis-Plus在確定操作的表時，由BaseMapper的泛型決定，即實體類型決定，且默認操作的表名和實體類型的類名一致

若實體類類型的類名和要操作的表的表名不一致，會出現什么問題？

我們將表user更名為t_user ，測試查詢功能

程序拋出異常，? Table 'mybatis_plus.user'doesn't exist，因為現在的表名為t_user ，而默認操作的表名和實體類型的類名一致，即user表

通過@TableName解決問題

??? 在實體類類型上添加@TableName("t_user")，標識實體類對應的表，即可成功執行SQL語句

通過全局配置解決問題

在開發的過程中，我們經常遇到以上的問題，即實體類所對應的表都有固定的前綴，例如t_或tbl_

此時，可以使用MyBatis-Plus提供的全局配置，為實體類所對應的表名設置默認的前綴，那么就不需要在每個實體類上通過@TableName標識實體類對應的表

mybatis-plus:

configuration:

# 配置MyBatis日志

log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

global-config:

db-config:

# 配置MyBatis-Plus操作表的默認前綴

table-prefix: t_

@TableId

經過以上的測試，? MyBatis-Plus在實現CRUD時，會默認將id作為主鍵列，并在插入數據時，默認基于雪花算法的策略生成id

a>問題

若實體類和表中表示主鍵的不是id，而是其他字段，例如uid ， MyBatis-Plus會自動識別uid為主鍵列嗎？

我們實體類中的屬性id改為uid，將表中的字段id也改為uid，測試添加功能

程序拋出異常，? Field 'uid'doesn't have a default value，說明MyBatis-Plus沒有將uid作為主鍵賦值

通過@TableId解決問題

??? 在實體類中uid屬性上通過@TableId將其標識為主鍵，即可成功執行SQL語句

c>@TableId的value屬性

若實體類中主鍵對應的屬性為id，而表中表示主鍵的字段為uid，此時若只在屬性id上添加注解???? @TableId，則拋出異常Unknown column'id'in'field list'，即MyBatis-Plus仍然會將id作為表的主鍵操作，而表中表示主鍵的是字段uid

此時需要通過@TableId注解的value屬性，指定表中的主鍵字段，? @TableId("uid")或

@TableId(value="uid")

@TableId的type屬性

??? type屬性用來定義主鍵策略

常用的主鍵策略：

值	描述
IdType.ASSIGN_ID （默認）	基于雪花算法的策略生成數據id，與數據庫id是否設置自增無關
IdType.AUTO	使用數據庫的自增策略，注意，該類型請確保數據庫設置了id自增，否則無效

配置全局主鍵策略：

mybatis-plus:

configuration:

# 配置MyBatis日志

log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

global-config:

db-config:

# 配置MyBatis-Plus操作表的默認前綴

table-prefix: t_

# 配置MyBatis-Plus的主鍵策略

id-type: auto

雪花算法

? 背景

需要選擇合適的方案去應對數據規模的增長，以應對逐漸增長的訪問壓力和數據量。

數據庫的擴展方式主要包括：業務分庫、主從復制，數據庫分表。

? 數據庫分表

將不同業務數據分散存儲到不同的數據庫服務器，能夠支撐百萬甚至千萬用戶規模的業務，但如果業務繼續發展，同一業務的單表數據也會達到單臺數據庫服務器的處理瓶頸。例如，淘寶的幾億用戶數據，? 如果全部存放在一臺數據庫服務器的一張表中，肯定是無法滿足性能要求的，此時就需要對單表數據進行拆分。

單表數據拆分有兩種方式：垂直分表和水平分表。示意圖如下：

? 垂直分表

垂直分表適合將表中某些不常用且占了大量空間的列拆分出去。

例如，前面示意圖中的 nickname 和 description 字段，假設我們是一個婚戀網站，用戶在篩選其他用? 戶的時候，主要是用 age 和 sex 兩個字段進行查詢，而 nickname 和 description 兩個字段主要用于展示，一般不會在業務查詢中用到。description 本身又比較長，因此我們可以將這兩個字段獨立到另外?? 一張表中，這樣在查詢 age 和 sex 時，就能帶來一定的性能提升。