数据库设计中自然键到底有啥用，为什么不能全靠人工生成的主键呢

关于数据库设计中自然键和人工主键的争论，其实是一个很经典的话题，自然键就是现实中已经存在的、有实际意义的标识符，比如一个人的身份证号、一本书的ISBN号、一个公司的统一社会信用代码，而人工主键（也叫代理键）则是我们为了数据库管理方便，凭空生成的一个标识符，通常是一个自增的数字（如1,2,3...）或者UUID（一串全球唯一的编码）。

既然我们可以很方便地创建一个与业务无关的、绝对不会重复的人工主键，为什么还要考虑使用自然键呢？难道不能全靠人工生成的主键吗？答案是不能一概而论,自然键有其不可替代的价值。

自然键的核心价值：天生的唯一性与业务约束

也是最重要的一点，自然键本身就是一种最强的业务规则体现，当我们把一个字段（如身份证号）设为主键时，我们不仅仅是在说“这个值不能重复”，更是在数据库层面庄严宣告：“在我们的业务世界里，身份证号就是唯一识别一个人的根本依据。” 这是一种强制性的业务逻辑约束。

如果完全依赖人工主键，而只把身份证号作为一个普通的唯一索引，那么在理论上，就有可能发生数据录入错误，导致两个不同的人工ID对应了同一个身份证号，虽然通过程序逻辑可以避免，但数据库本身失去了一层最根本的保障，而将身份证号设为主键，数据库引擎会在最底层阻止这种根本性错误的发生，正如数据库专家乔· Celko 在其著作《SQL for Smarties》中强调的，主键的首要职责是保证实体的完整性,而自然键往往是实现这一目标最直接的方式。

提升可读性与简化查询

自然键能极大地提升数据的可读性和查询的便利性，想象一下，当你查看一张“订单表”时，如果主键是一个像“202405210001”这样的订单号（自然键），你一眼就能看出这是2024年5月21日的第一个订单，这个编号本身携带了业务信息，但如果你看到的只是一个毫无意义的数字“47821”,你就必须去关联查询才能知道这个订单到底是什么。

在编写复杂的SQL查询时，使用自然键作为关联条件往往更直观，查询“购买了ISBN为9787115279460这本书的所有顾客”，这样的语句非常清晰，如果全部使用人工ID，查询就会变成“通过书籍表的人工主键ID，关联到库存表，再关联到订单明细表，再...”，语句会变得冗长且难以理解，这正如在实践社区中许多开发者所体会到的，自然键能让SQL“更干净”,减少不必要的表连接。

避免不必要的表连接

承接上一点，使用自然键有时可以直接避免多余的表连接，在一些报表查询或数据分析场景中，如果维度表（如产品表、客户表）使用有意义的自然键作为主键，那么事实表（如销售记录表）可以直接存储这个自然键，这样，在生成报表时，可能不需要去连接维度表就能直接获取到关键信息（比如产品编码本身就有分类信息），而如果使用人工ID，则每次都必须进行表连接才能看到有意义的描述，在大数据量查询时,这会成为性能瓶颈。

人工主键的陷阱

反过来看，如果完全抛弃自然键，全靠人工主键,也会带来一些问题：

1. “唯ID论”的泛滥：数据库中会充斥着大量无意义的ID字段，每个表都有一个id，但光看这个id你完全不知道它代表什么，这会使数据库 schema 变得抽象和难以理解,增加了新成员熟悉系统的成本。
2. 唯一性约束的松懈：开发人员可能会认为有了人工主键就万事大吉，从而忽略了在业务上本应唯一的字段（如用户名、邮箱）上建立唯一约束，这可能导致脏数据的产生，比如系统中存在两个用户名相同的用户,尽管他们的人工ID不同。
3. 数据合并与迁移的挑战：当需要合并两个独立开发的系统时，如果它们都使用自增数字作为主键，极有可能发生ID冲突，导致合并过程异常复杂，而如果系统使用的是全局唯一的自然键（如身份证号）,合并就会顺畅得多。

为什么不能全靠自然键呢？

既然自然键这么好，为什么它也不是万能的？这正是问题的另一面,也是人工主键存在的原因。

• 不稳定性的风险：这是自然键最大的“阿喀琉斯之踵”，如果自然键本身发生变化，将会是数据库的一场灾难，假设一个国家的公民身份证号系统改革，所有人的号码都变了，那么所有以身份证号作为外键关联的表都需要进行级联更新，操作风险极高，而人工主键一旦生成,就永不改变。
• 复杂性：有些实体的自然键可能是由多个字段组成的复合键（比如一门课程可能由“院系代码+课程代码+开课学期”唯一确定），使用复合键作为主键，会使外键关联和查询语句变得稍微复杂，在某些ORM（对象关系映射）框架中,对复合键的支持也不如单字段主键那么好。
• 缺乏简单性：像UUID这样的自然键虽然全局唯一，但长度很长，作为主键特别是作为其他表的外键时，会占用更多存储空间，并可能影响索引性能和查询速度,自增整数在存储和索引效率上通常更高。

混合使用，各司其职

最理性的做法不是二选一，而是根据具体场景混合使用,让它们各司其职。

一个良好的设计策略是：

1. 优先寻找稳定、简单、唯一的自然键作为主键的候选，比如身份证号、ISBN号,它们就是非常理想的选择。
2. 如果自然键存在不稳定、过于复杂或效率低下的问题，则果断使用人工主键（如自增ID或UUID），但同时，必须在原本的自然键候选字段上创建唯一的约束索引。
3. 人工主键负责保证技术层面的唯一性和连接效率，它稳定不变，是表关系的“锚点”。
4. 自然键（即使不作为主键）上的唯一约束负责保证业务层面的数据正确性,防止重复和无效数据录入。

简而言之，人工主键是数据库的“骨架”，提供了稳定和高效的结构；而自然键及其约束则是数据库的“灵魂”，确保了数据真实反映了业务世界的规则，二者相辅相成，缺一不可，完全依赖任何一方而忽视另一方,都可能给数据库的长期维护和数据质量埋下隐患。