ID主键怎么选 - 主键类型与选型建议

前言：

ID主键的选型看似非常小的事情，却影响着整个系统架构设计的地基，以及后续的开发维护代价。这篇文章我们就来详细说明一下ID主键的类型、各自优缺点，以及选型建议。

ID主键的类型：

我们开发中常用的ID主键类型一般有以下3种：

主键类型	示例
数据库自增ID	1001
UUID	550e8400-e29b-41d4-a716-446655440000
雪花算法ID	1610219533249941504

各自优缺点

1. 数据库自增ID (Auto-increment)：

优点:

1. 存储空间和性能：自增ID占用空间小，有序索引效率高。
2. 简单：易于实现，数据库系统可以直接生成。

缺点:

1. 安全性：自增ID可能会泄露业务信息，如通过ID可以推算出用户增长趋势。
2. 扩展性：依赖数据库，不易迁移。分布式系统中难以保证唯一性。

提示建议:

• 敏感数据如果用自增ID，必须加数据权限过滤，防止数据泄露；
• 需要跟外部系统数据对接时慎用，自增ID无法保证唯一性，会增加复杂度；

2. UUID (Universally Unique Identifier)：

优点:

1. 全局唯一性：在分布式系统中，UUID可以保证全局唯一。
2. 安全性好：不泄露业务信息，因为UUID是随机生成的。
3. 不依赖数据库：可以在应用层生成，不依赖数据库。

缺点:

1. 存储空间和性能：存储空间较大（通常36），UUID无序导致索引性能不如有序ID
2. 维护不便：程序中（或数据库客户端）显示记录，必须结合创建时间排序才能有序

比如通过数据库管理工具排查问题查看数据时，记录显示是无序的，必须先按“创建时间”字段排序后再查看。同样，前端列表中显示时也需要先按“创建时间”排序后展示，这就需要额外给“创建时间”添加索引。而有序ID则可以直接以ID排序即等效于时间顺序。

提示建议:

• 需要借助时间戳字段排序后得到有序结果，时间戳字段需要索引；

注：Diboot 低代码开发框架 中的文件记录表采用的是UUID类型主键，防止ID被猜测，提高安全性。

3. 雪花ID (Snowflake ID)：

优点:

1. 全局唯一性：适合分布式系统，可以生成全局唯一的ID。
2. 高效性：结合了自增ID和UUID的优点，既有序又全局唯一，安全性也介于二者之间。

缺点:

1. 依赖时间：依赖时间：依赖于时间戳，如果时间回拨或有误会影响ID的生成。

提示建议:

• 如果后端是Long型，序列化到前端时需要转String，否则会出现JS精度丢失问题；
• 建议采用String类型，避免很多无谓的转换，更好的适配数据集成中的其他类型ID；

注：Diboot 低代码开发框架 中的系统表均采用的是String类型雪花ID的主键，提高效率的同时也规避了很多坑。

除了以上常用的ID类型，还有针对海量并发场景的分布式ID生成算法，如 美团的 Leaf，此处不过多介绍。