默認的主鍵生成策略共有5種: * AUTO: 主鍵自增 * NONE: 不設置id生成策略 * INPUT:用戶手工輸入id * ASSIGN_ID:雪花算法生成id(可兼容數值型與字符串型) * ASSIGN_UUID:以UUID生成算法作為id生成策略 * 其他的幾個策略均已過時，都將被ASSIGN\_ID和ASSIGN\_UUID代替掉。 ``` @Data @TableName("tbl_user") public class User { @TableId(type = IdType.AUTO) private Long id; private String name; @TableField(value="pwd",select=false) private String password; private Integer age; private String tel; @TableField(exist=false) private Integer online; } ```  **拓展:** 分布式ID是什么? * 當數據量足夠大的時候，一臺數據庫服務器存儲不下，這個時候就需要多臺數據庫服務器進行存儲 * 比如訂單表就有可能被存儲在不同的服務器上 * 如果用數據庫表的自增主鍵，因為在兩臺服務器上所以會出現沖突 * 這個時候就需要一個全局唯一ID,這個ID就是分布式ID。 # ID生成策略對比 介紹了這些主鍵ID的生成策略，我們以后該用哪個呢? * NONE: 不設置id生成策略，MP不自動生成，約等于INPUT,所以這兩種方式都需要用戶手動設置，但是手動設置第一個問題是容易出現相同的ID造成主鍵沖突，為了保證主鍵不沖突就需要做很多判定，實現起來比較復雜 * AUTO:數據庫ID自增,這種策略適合在數據庫服務器只有1臺的情況下使用,不可作為分布式ID使用 * ASSIGN_UUID:可以在分布式的情況下使用，而且能夠保證唯一，但是生成的主鍵是32位的字符串，長度過長占用空間而且還不能排序，查詢性能也慢 * ASSIGN_ID:可以在分布式的情況下使用，生成的是Long類型的數字，可以排序性能也高，但是生成的策略和服務器時間有關，如果修改了系統時間就有可能導致出現重復主鍵 綜上所述，每一種主鍵策略都有自己的優缺點，根據自己項目業務的實際情況來選擇使用才是最明智的選擇。