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

不同的表的id：

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

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

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

關(guān)系表：可省略id

……

不同的業(yè)務(wù)采用的ID生成方式應(yīng)該是不一樣的，那么在MyBatisPlus（以下簡稱MP）中都提供了哪些主鍵生成策略，以及我們?cè)撊绾芜M(jìn)行選擇?  

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

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

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

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

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

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

 AUTO

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

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

NONE

不設(shè)置id生成策略，MP不自動(dòng)生成，約等于INPUT

INPUT

這種ID生成策略，需要將表的自增策略刪除掉，然后手動(dòng)設(shè)置ID值

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

ASSIGN_ID

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

雪花算法：

雪花算法生成的是一個(gè)64bit大小的整數(shù)（對(duì)應(yīng)Long）

時(shí)間戳：用來記錄時(shí)間戳，毫秒級(jí)

工作機(jī)器id：用來記錄工作機(jī)器id

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

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

ASSIGN_UUID

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

因此使用ASSIGN_UUID時(shí)需要注意：

• 實(shí)體類的主鍵類型不能是Long，而應(yīng)該改成String類型
• 表中的主鍵類型設(shè)置為varchar，長度要大于32，如果長度小的話就會(huì)導(dǎo)致插入失敗

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

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