唯一ID应选择随机生成还是自增生成方式？

没有绝对合理或不合理的ID生成方案，自增ID和随机ID不存在通用的最优解，选型完全匹配业务场景即可，以下是两种方案的实际生产表现和明确的选型判断标准：

自增ID本身是非常成熟的工业级实现，不存在“天然不合理”的问题，它的核心优势非常明确：

• 实现成本极低，主流关系型数据库都提供原生支持，比如MySQL的AUTO_INCREMENT、PostgreSQL的BIGSERIAL，不需要额外引入组件、编写额外生成逻辑，单库场景下零冲突
• 存储和查询性能拉满：自增ID是连续顺序值，作为数据库主键时，B+树索引是顺序追加写入，完全不会触发随机页分裂，相同数据量下索引体积比随机ID小30%以上，写入、查询性能都是最优档
• 排错效率高：ID值的大小直接对应数据生成的先后顺序，排查数据问题、追溯数据写入时间的时候，不需要额外查创建时间字段，靠ID就能快速定位范围

但它的缺陷也非常致命，在不符合场景的情况下使用就会出问题：

• 可枚举性太强：如果ID暴露给外部用户，攻击者只要按顺序递增值发起请求，就能爬取全量业务数据，甚至直接通过ID差值算出你的真实业务规模（比如订单ID一天从100万涨到120万，其他人直接能推算出单日单量规模）
• 分布式场景适配成本高：多实例部署、分库分表的架构下，原生自增ID会出现重复，必须额外搭建统一发号器、配置不同实例的ID步长偏移，架构维护成本会明显上升
• 跨系统数据合并麻烦：如果要把两个同结构的业务库数据合并，两边的自增ID大概率会大量重复，需要做二次ID映射，迁移成本高

这里说的随机ID指的是本地生成、无全局协调的无序ID，最常见的是128位的UUIDv4，它的优势刚好补了自增ID的短板：

• 无规律、不可枚举：对外暴露的时候，外部用户无法通过已有ID推算出其他有效ID，天然防爬、防业务数据泄露
• 分布式适配成本为0：只要ID长度足够（比如128位），不需要中心发号节点，每个服务实例本地就能生成，冲突概率低到可以忽略，多地域部署、分库分表场景下直接用就行，不会出现ID重复
• 跨系统数据合并友好：不同系统独立生成的随机ID重复概率极低，数据合并的时候不需要做额外的ID转换

它的缺陷同样明显：

• 数据库写入性能差：完全无序的随机值作为主键写入时，会频繁触发B+树索引的页分裂、页合并，高写入压力下性能比自增ID低30%~50%，且ID本身长度更长，会占用更多存储
• 排错成本高：ID本身不携带任何时序信息，没法通过ID判断数据生成顺序，排查问题的时候必须依赖额外的时间字段
• 短ID冲突风险高：如果为了可读性用短长度的随机ID（比如6位、8位数字/字符串），生成量上来之后冲突概率会快速升高，根本无法满足唯一ID的要求

不用纠结哪种方案“更高级”，按下面三个维度判断即可：

1. 看ID是否对外暴露

   仅在内部服务、内部系统流转，完全不返回给前端、外部合作方的ID，直接选自增ID，性价比最高
   需要拼在公开URL、返回给C端用户、传递给外部合作方的ID，优先选随机ID，避免数据泄露风险

2. 看架构复杂度

   单库单表的单体应用、没有分布式部署/分库分表规划的，自增ID是最优选择
   已经做了分布式部署、分库分表，且不想额外维护统一发号器的，选符合长度要求的随机ID即可；如果能接受发号器的维护成本，也可以选趋势递增的分布式ID（比如雪花ID），兼顾性能和分布式适配能力

3. 看性能要求

   写入QPS极高的核心链路（比如日志存储、埋点上报、大流量交易记录），优先选自增或趋势递增ID，把随机写带来的性能损耗降到最低
   写入QPS不高的普通业务场景，随机ID带来的性能损耗完全可以被硬件能力覆盖，不需要为了极致性能牺牲安全性

内容的提问来源于stack exchange，提问作者Jamsr