Mybatis-Plus3.0默認主鍵策略導致自動生成19位長度主鍵id的坑

碼字不易，如果對您有用，求各位看官點贊關注~

原創/朱季謙

目前的Mybatis-Plus版本是3.0，至於最新版本是否已經沒有這個問題，後續再考慮研究。

某天檢查一位離職同事寫的代碼，發現其對應表雖然設置了AUTO_INCREMENT自增，但頁面新增功能生成的數據主鍵id很詭異，長度達到了19位，且不是從1開始遞增的——

我檢查了一下，發現該表目前自增主鍵已經變成從1468844351843872770開始遞增了——

這就很奇怪了，目前該表數據量很少，且主鍵是設置AUTO_INCREMENT，正常而言，應該自增id仍在1000範圍內，但目前已經變成一串長數字。

底層ORM框架用的是Mybatis-Plus，我尋思了一下，這看起來像是在插入數據庫就自動生成的id，導致並非默認使用MySql的自增AUTO_INCREMENT來生成id。

因此，決定一步步定位，先給Mybatis-Plus打印出sql日誌，看下其insert語句是否自動生成了一個id後才插入數據庫。

按照網上的教程，我在yaml文件裏對應的mybatis-plus配置處設置了開啓sql打印日誌——

mybatis-plus:
  mapper-locations: classpath*:mapper/*.xml
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

然而，很詭異的是，執行操作時並沒有打印出sql日誌，故而，某一瞬間，我忽然覺得，這羣傢伙可能都是互相抄的，沒有驗證當springboot集成了logback時，單純這樣設置並沒有效果。

最後額外在yaml加了以下配置，才能正常打印MP的sql日誌信息——

logging:
  level:
    com:
      zhu:
        test:
          mapper: debug

接下來，驗證一番後，發現，Mybatis-Plus在做insert操作時，確實自動生成一條長19的數字當做該條數據的id插入到MySql，導致雖然MySql表設置了自增，但被Mybatis-Plus生成的id爲1468844351843872769所影響，導致下一條數據自動遞增值變成1468844351843872770，這種過長的id值，在做索引維護時，是很影響效率，佔用空間過大，故而，這個問題必須得解決。

到這裏，就確定，這個長數字的id，是在代碼層次就自動生成了，最後進入對應的實體類中，發現該映射數據表的id字段，並沒有顯示設置對應的主鍵生成策略。

@Data
@TableName("test")
public class Test extends Model<Test> implements Serializable {
    
    private Long id;
    ......
}

Mybatis-Plus主要有以下幾種主鍵生成策略——

@Getter
public enum IdType {
    /**
     * 數據庫ID自增
     */
    AUTO(0),
    /**
     * 該類型爲未設置主鍵類型
     */
    NONE(1),
    /**
     * 用戶輸入ID
     * 該類型可以通過自己註冊自動填充插件進行填充
     */
    INPUT(2),

    /* 以下3種類型、只有當插入對象ID 爲空，才自動填充。 */
    /**
     * 全局唯一ID (idWorker)，根據雪花算法生成19位數字，long類型
     */
    ID_WORKER(3),
    /**
     * 全局唯一ID (UUID)
     */
    UUID(4),
    /**
     * 字符串全局唯一ID (idWorker 的字符串表示)，根據雪花算法生成19位字符串，String
     */
    ID_WORKER_STR(5);

    private int key;

    IdType(int key) {
        this.key = key;
    }
}

這裏驗證了一下，當設置成這樣時，就能正常生成數據庫自增的id了，使用數據庫AUTO_INCREMENT從1開始自增的效果了，當然，其實使用IdType.AUTO也是可以的——

@Data
@TableName("test")
public class Test extends Model<Test> implements Serializable {
    @TableId(value = "id", type = IdType.INPUT)
    private Long id;
    ......
}

百度網上的說法，當Mybatis-Plus實體類沒有顯示設置主鍵策略時，將默認使用雪花算法生成，也就是IdType.ID_WORKER或者IdType.ID_WORKER_STR，具體是long類型的19位還是字符串的19位，應該是根據字段定義類型來判斷。

snowflake算法是Twitter開源的分佈式ID生成算法，結果是一個long類型的ID 。其核心思想：使用41bit作爲毫秒數，10bit作爲機器的ID（5bit數據中心，5bit的機器ID），12bit作爲毫秒內的流水號（意味着每個節點在每個毫秒可以產生4096個ID），最後還有一個符號位，永遠是0。

接下來，先驗證Mybatis-Plus默認主鍵策略是如何的。

Mybatis-Plus項目在啓動時，會對註解實體類進行初始化，然後緩存到系統Map中。

這裏，只需要關注Mybatis-Plus源碼TableInfoHelper類中的initTableInfo方法即可，這個方法在項目啓動時會被調用，然後初始化所有註解@TableName的實體類。與主鍵根據哪種策略來設置的邏輯在方法initTableFields(clazz, globalConfig, tableInfo)當中——

public synchronized static TableInfo initTableInfo(MapperBuilderAssistant builderAssistant, Class<?> clazz) {
    TableInfo tableInfo = TABLE_INFO_CACHE.get(clazz.getName());
    if (tableInfo != null) {
        if (tableInfo.getConfigMark() == null && builderAssistant != null) {
            tableInfo.setConfigMark(builderAssistant.getConfiguration());
        }
        return tableInfo;
    }

    /* 沒有獲取到緩存信息,則初始化 */
    tableInfo = new TableInfo();
    GlobalConfig globalConfig;
    if (null != builderAssistant) {
        tableInfo.setCurrentNamespace(builderAssistant.getCurrentNamespace());
        tableInfo.setConfigMark(builderAssistant.getConfiguration());
        tableInfo.setUnderCamel(builderAssistant.getConfiguration().isMapUnderscoreToCamelCase());
        globalConfig = GlobalConfigUtils.getGlobalConfig(builderAssistant.getConfiguration());
    } else {
        // 兼容測試場景
        globalConfig = GlobalConfigUtils.defaults();
    }

    /* 初始化表名相關 */
    initTableName(clazz, globalConfig, tableInfo);

    /* 初始化字段相關 */
    initTableFields(clazz, globalConfig, tableInfo);

    /* 放入緩存 */
    TABLE_INFO_CACHE.put(clazz.getName(), tableInfo);

    /* 緩存 Lambda 映射關係 */
    LambdaUtils.createCache(clazz, tableInfo);
    return tableInfo;
}

在初始化字段相關的initTableFields方法裏，會判斷是否有@TableId 註解，如果沒有，就執行initTableIdWithoutAnnotation方法，連續前文提到的，如果實體類id沒有加@TableId(value = "id", type = IdType.INPUT)，那麼就會取默認的主鍵策略。這裏的判斷是否有@TableId 註解，就是判斷是否需要取默認的主鍵策略，至於具體是如何設置默認主鍵的，我們可以直接進入到initTableIdWithoutAnnotation方法當中。

public static void initTableFields(Class<?> clazz, GlobalConfig globalConfig, TableInfo tableInfo) {
    /* 數據庫全局配置 */
    GlobalConfig.DbConfig dbConfig = globalConfig.getDbConfig();
    List<Field> list = getAllFields(clazz);
    // 標記是否讀取到主鍵
    boolean isReadPK = false;
    // 是否存在 @TableId 註解
    boolean existTableId = isExistTableId(list);

    List<TableFieldInfo> fieldList = new ArrayList<>();
    for (Field field : list) {
        /*
         * 主鍵ID 初始化
         */
        if (!isReadPK) {
            if (existTableId) {
                isReadPK = initTableIdWithAnnotation(dbConfig, tableInfo, field, clazz);
            } else {
                isReadPK = initTableIdWithoutAnnotation(dbConfig, tableInfo, field, clazz);
            }
            if (isReadPK) {
                continue;
            }
        }
       ......
    }
   ......
}

initTableIdWithoutAnnotation方法——

private static final String DEFAULT_ID_NAME = "id";
/**
 * <p>
 * 主鍵屬性初始化
 * </p>
 *
 * @param tableInfo 表信息
 * @param field     字段
 * @param clazz     實體類
 * @return true 繼續下一個屬性判斷，返回 continue;
 */
private static boolean initTableIdWithoutAnnotation(GlobalConfig.DbConfig dbConfig, TableInfo tableInfo,
                                                 Field field, Class<?> clazz) {
    //獲取實體類字段名
    String column = field.getName();
    if (dbConfig.isCapitalMode()) {
        column = column.toUpperCase();
    }
    //當字段名爲id
    if (DEFAULT_ID_NAME.equalsIgnoreCase(column)) {
        if (StringUtils.isEmpty(tableInfo.getKeyColumn())) {
            tableInfo.setKeyRelated(checkRelated(tableInfo.isUnderCamel(), field.getName(), column))
                //設置表策略
                .setIdType(dbConfig.getIdType())
                .setKeyColumn(column)
                .setKeyProperty(field.getName())
                .setClazz(field.getDeclaringClass());
            return true;
        } else {
            throwExceptionId(clazz);
        }
    }
    return false;
}

Debug到這裏，可以看到，如果沒有 @TableId 註解顯示設置主鍵策略情況下，默認設置的是 ID_WORKER(3)，即會根據雪花算法生成19位數字，long類型。

可以進一步發現，這裏的 dbConfig是GlobalConfig.DbConfig實例，進入到DbConfig類，可以看到原來實體類映射的數據庫設置在這裏，主鍵類型默認是IdType.ID_WORKER。

@Data
public static class DbConfig {

    /**
     * 數據庫類型
     */
    private DbType dbType = DbType.OTHER;
    /**
     * 主鍵類型（默認 ID_WORKER）
     */
    private IdType idType = IdType.ID_WORKER;
    /**
     * 表名前綴
     */
    private String tablePrefix;
    /**
     * 表名、是否使用下劃線命名（默認 true:默認數據庫表下劃線命名）
     */
    private boolean tableUnderline = true;
    /**
     * String 類型字段 LIKE
     */
    private boolean columnLike = false;
    /**
     * 大寫命名
     */
    private boolean capitalMode = false;
    /**
     * 表關鍵詞 key 生成器
     */
    private IKeyGenerator keyGenerator;
    /**
     * 邏輯刪除全局值（默認 1、表示已刪除）
     */
    private String logicDeleteValue = "1";
    /**
     * 邏輯未刪除全局值（默認 0、表示未刪除）
     */
    private String logicNotDeleteValue = "0";
    /**
     * 字段驗證策略
     */
    private FieldStrategy fieldStrategy = FieldStrategy.NOT_NULL;
}

至於如何生成雪花算法id，這裏就不一一詳細介紹，具體邏輯是在MybatisDefaultParameterHandler類populateKeys方法裏，核心代碼如下——

protected static Object populateKeys(MetaObjectHandler metaObjectHandler, TableInfo tableInfo,
                                     MappedStatement ms, Object parameterObject, boolean isInsert) {
    if (null == tableInfo) {
        /* 不處理 */
        return parameterObject;
    }
    /* 自定義元對象填充控制器 */
    MetaObject metaObject = ms.getConfiguration().newMetaObject(parameterObject);
    // 填充主鍵
    if (isInsert && !StringUtils.isEmpty(tableInfo.getKeyProperty())
        && null != tableInfo.getIdType() && tableInfo.getIdType().getKey() >= 3) {
        Object idValue = metaObject.getValue(tableInfo.getKeyProperty());
        /* 自定義 ID */
        if (StringUtils.checkValNull(idValue)) {
            if (tableInfo.getIdType() == IdType.ID_WORKER) {
                metaObject.setValue(tableInfo.getKeyProperty(), IdWorker.getId());
            } else if (tableInfo.getIdType() == IdType.ID_WORKER_STR) {
                metaObject.setValue(tableInfo.getKeyProperty(), IdWorker.getIdStr());
            } else if (tableInfo.getIdType() == IdType.UUID) {
                metaObject.setValue(tableInfo.getKeyProperty(), IdWorker.get32UUID());
            }
        }
    }
   ......
}

前邊提到，默認的主鍵策略是IdType.ID_WORKER，這裏有一個判斷tableInfo.getIdType() == IdType.ID_WORKER，對代碼Debug可以看到，metaObject的setValue(tableInfo.getKeyProperty(), IdWorker.getId())代碼的作用，是對註解id進行了值填充。

填充的值爲IdWorker.getId()返回的1468970800437465089，剛好是19位長度，這就意味着，這裏產生的id值，就是我們最後要找的。

IdWorker.getId()實現本質，正好是基於Snowflake實現64位自增ID算法，而Snowflake，正是引用了雪花算法——

/**
 * <p>
 * 高效GUID產生算法(sequence),基於Snowflake實現64位自增ID算法。 <br>
 * 優化開源項目 http://git.oschina.net/yu120/sequence
 * </p>
 *
 * @author hubin
 * @since 2016-08-01
 */
public class IdWorker {

    /**
     * 主機和進程的機器碼
     */
    private static final Sequence WORKER = new Sequence();

    public static long getId() {
        return WORKER.nextId();
    }

    public static String getIdStr() {
        return String.valueOf(WORKER.nextId());
    }

    /**
     * <p>
     * 獲取去掉"-" UUID
     * </p>
     */
    public static synchronized String get32UUID() {
        return UUID.randomUUID().toString().replace(StringPool.DASH, StringPool.EMPTY);
    }

}

Mybatis-Plus3.0默認主鍵策略導致自動生成19位長度主鍵id的坑

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

kafka源碼閱讀之MacBook Pro M1搭建Kafka2.7版本源碼運行環境

Docker部署系列之Docker Compose安裝Redis三主三從集羣

基於源碼理解通透Iterator迭代器的Fail-Fast快速失敗與Fail-Safe安全失敗機制

[2023年度回顧總結]凡是過往,皆爲序章

Java SPI機制總結系列之萬字最詳細圖解Java SPI機制源碼分析

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結