文章摘要：自增 ID 与 UUID 的选择

本文讨论在新系统架构设计中，如何在自增 ID 和 UUID 中做出选择。作者首先对相关概念进行澄清，包括数据库 ID、业务编码、自增 ID、UUID、自然主键和代理主键。

概念澄清

文章指出，ID 可以根据业务用途、实现方式和主键选择分类。数据库 ID 通常用作数据存储的唯一标识，可由自增 ID 和 UUID 实现。业务编码在业务上有一定含义，可能非唯一。自增 ID 是数据库内部实现的数字，单调递增且唯一。UUID 是独立于数据的、由规则生成的 ID。自然主键使用业务含义的键，而代理主键使用与业务无关的 ID。

自增 ID 和 UUID 的问题

自增 ID 存在数据迁移唯一性难题、ORM 使用不便、幂等性处理不便、高并发性能问题、数据增长可预测、长度限制和分库分表唯一性问题。UUID 则可能在配置不良时重复、占用更大存储空间、丢失自然排序能力、可读性差，且不符合日常使用习惯。

架构师经历和选择

在技术决策时，架构师的选择往往受到技术惯性的影响。一些架构师会根据习惯选择自增 ID，而另外一些则考虑到UUID的便利性。

自然主键与代理主键的选择

讨论了完全使用自然主键、完全使用代理主键以及自然主键优先的三种方案。建议采用自然主键优先的方案，以平衡设计的统一性和实用性。

其他常见问题

对于已经使用自增 ID 的系统分库分表问题，建议添加 UUID key 作为全局唯一标识。在外部系统中暴露 ID 时，优先考虑业务编码，内部系统则可以使用自增 ID。创业公司倾向于使用自增 ID，而互联网大厂更多采用 UUID。

新系统 ID 选择和注意事项

对于新系统的 ID 选择，建议根据业务规模和团队习惯来决定。在 NoSQL 环境下，通常默认使用 UUID。UUID 的生成不依赖数据库主节点，在需要有序的情况下可以考虑 ULID 方案。

文章最后提供了几篇相关主题的推荐阅读，并鼓励读者关注作者的公众号和知乎账号。

为什么不直接让开发兼任测试？

了解更多

TechLead 少个分号

查看原文：系统设计 | UUID 和 自增 ID 怎么选？

文章来源：

TechLead 少个分号

扫码关注公众号