一、為什么需要選擇不同的id生成策略

不同的表的id：

日志：自增（1,2,3,4，……）

購物訂單：特殊規(guī)則（FQ23948AK3843）

外賣單：關聯(lián)地區(qū)日期等信息（10 04 20200314 34 91）

關系表：可省略id

……

不同的業(yè)務采用的ID生成方式應該是不一樣的，那么在MyBatisPlus（以下簡稱MP）中都提供了哪些主鍵生成策略，以及我們該如何進行選擇?  

二、如何使用MP的id生成策略

這里需要使用到一個注解 @TableId( type = id生成策略 ) ，將改注解加到實體類的id屬性上，如下：

@Data
@TableName("tbl_user")
public class User {
 
    @TableId(type = IdType.AUTO)
    private Long id;
 
    ...
 
}

其中的id生成策略的取值來自枚舉類 IdType 如下：

 從源碼中可以看到，公有如下幾種生成策略:

• AUTO：id自增
• NONE: 不設置id生成策略
• INPUT:用戶手工輸入id
• ASSIGN_ID:雪花算法生成id
• ASSIGN_UUID:以UUID生成算法作為id生成策略
• 其他的幾個策略均已過時，都將被ASSIGN_ID和ASSIGN_UUID代替掉。

 AUTO

使用AUTO策略的時候一定要確保對應的數(shù)據(jù)庫表設置了ID主鍵自增，否則無效

另外，AUTO策略不能在分布式系統(tǒng)中使用，因為每臺數(shù)據(jù)庫服務器如果都基于本地的最新ID進行自增，那就會出現(xiàn)ID沖突

NONE

不設置id生成策略，MP不自動生成，約等于INPUT

INPUT

這種ID生成策略，需要將表的自增策略刪除掉，然后手動設置ID值

    void userSave(){
        User user = new User();
        //設置主鍵ID的值
        user.setId(123456L);
        
        //為其他屬性賦值...
 
        userDao.insert(user);
    }

ASSIGN_ID

采用該策略時，如果用戶自己設置ID，MP會使用用戶設置的ID，如果用戶不自己設置ID值，那么MP會根據(jù)雪花算法自動生成ID，該策略可在分布式系統(tǒng)中使用

雪花算法：

雪花算法生成的是一個64bit大小的整數(shù)（對應Long）

時間戳：用來記錄時間戳，毫秒級

工作機器id：用來記錄工作機器id

序列號：占用12bit，每個節(jié)點每毫秒0開始不斷累加，最多可以累加到4095，一共可以產(chǎn)生4096個ID

從上面可以看出，ASSIGN_ID 生成的策略和服務器時間有關，如果修改了系統(tǒng)時間就有可能導致出現(xiàn)重復主鍵 ，這點需要注意

ASSIGN_UUID

ASSIGN_UUID是自動生成一個不重復的、長度為32位的字符串，也能在分布式系統(tǒng)中使用

因此使用ASSIGN_UUID時需要注意：

• 實體類的主鍵類型不能是Long，而應該改成String類型
• 表中的主鍵類型設置為varchar，長度要大于32，如果長度小的話就會導致插入失敗

ASSIGN_UUID的缺點比較明顯：生成的主鍵是32位的字符串，長度過長占用空間而且還不能排序，查詢性能也慢

到此這篇關于MyBatisPlus之id生成策略的方法的文章就介紹到這了,更多相關MyBatisPlus id生成策略內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論