碼字不易，如果對您有用，求各位看官點贊關注~
原創/朱季謙
目前的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/*.xmlconfiguration: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();}//當字段名為idif (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);}}
之hwclock)
