这似乎是关于 代理 键的问题， 代理 键始终是自动递增的数字或GUID，因此是单列，而 自然
键则通常需要多个信息才能真正唯一。如果您能够拥有仅一列的自然键，那么无论如何，这一点显然是没有意义的。

有些人会坚持只使用其中之一。花足够的时间使用生产数据库，您将了解到没有任何上下文无关的最佳实践。

其中一些答案使用SQL Server术语，但是这些概念通常适用于所有DBMS产品：

使用单列代理键的原因：

• 聚集索引。 当数据库只能附加聚簇索引时，聚簇索引总是表现最佳-否则，数据库必须进行页面拆分。请注意，这仅在键为 顺序 键（即自动递增顺序或顺序GUID）时适用。任意GUID的性能可能会更差。

• 关系。 如果你的关键是3，4，5列长，包括性格类型和其他非压缩数据，你会浪费 巨大 的空间量，然后，如果你要建立外键关系在其他20桌此键降低性能。

• 独特性 有时候，你并不 拥有 真实自然的关键。也许您的表是某种日志，并且您有可能同时获取两个相同的事件。也许您的真实键就像是物化路径，只能在已插入行 之后 才能确定。无论哪种方式，您始终希望聚簇索引和/或主键是唯一的，因此，如果没有其他真正唯一的信息，则别无选择，只能使用代理键。

• 兼容性。 大多数人将永远不必处理此问题，但是如果自然键包含类似的内容hierarchyid，则某些系统甚至可能无法读取它。在这种情况下， 必须 再次创建一个简单的自动生成的代理密钥，以供这些应用程序使用。即使您在自然键中没有任何“怪异”数据，某些数据库库在处理多列主键时也会遇到很多麻烦，尽管这个问题很快就消失了。

使用多列自然键的原因

• 贮存。 许多使用数据库的人从来没有使用过足够大的数据库，而不必关心这个因素。但是，当一个表具有数十亿或数万亿的行时，您将想要在该表中保留可能的绝对最小数据量。

• 复制。 是的，您可以使用GUID或顺序GUID。但是GUID有其自身的权衡，如果出于某种原因您不能使用GUID，则多列自然键是复制方案的更好选择，因为它 本质上 是 全局唯一的 -就是说，您不需要特殊的算法就可以使其具有唯一性， 根据定义 它是唯一 的 。这使得对分布式体系结构的推理变得非常容易。

• 插入/更新性能 。代理键不是免费的。如果您有一组唯一 且经常被查询的列，因此您需要在这些列上创建覆盖索引；索引最终几乎与表一样大，这浪费了空间，并且 每次进行任何修改时都需要更新第二个索引。如果表上可能只有 一个_索引（聚集索引），则应该这样做！

这就是马上想到的事情。如果我突然想起其他任何事情，我会进行更新。