有些人会坚持只使用一个或另一个.花费足够的时间与生产数据库合作,您将了解到,没有上下文无关的最佳做法.

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

使用单列替代键的原因：

>聚集索引当数据库只能追加到集群索引时,集群索引始终会执行最佳操作 – 否则,DB必须执行page splits.请注意,这仅适用于密钥是顺序的,即自动递增序列或顺序GUID.任意GUID可能会更糟糕的表现.
>关系如果您的键长为3,4,5列(包括字符类型和其他非紧凑型数据),则最终会浪费大量空间,如果必须在20个其他表中创建与该键的外键关系,则会降低性能.
>独特性有时你没有真正的自然键.也许你的桌子是某种日志,你可以同时获得两个相同的事件.或者也许你的真正的钥匙是一个物化路径,只能在行被插入后确定.无论哪种方式,您总是希望聚集索引和/或主键是唯一的,因此如果您没有其他真正唯一的信息,您别无选择,只能使用代理键.
>兼容性.大多数人将永远不会处理这个问题,但是如果自然键包含类似于层次结构的东西,那么有些系统甚至无法读取它.在这种情况下,您再次必须创建一个简单的自动生成代理键供这些应用程序使用.即使在自然键中没有任何“奇怪”的数据,一些DB库在处理多列主键时遇到了很多麻烦,尽管这个问题很快就消失了.

使用多列自然键的原因

>存储.许多使用数据库的人从来没有使用足够大的数据来关注这个因素.但是,当一个表有数十亿或数十亿行时,您将要保留此表中绝对最小数据量.
>复制.是的,您可以使用GUID或顺序GUID.但是GUID有自己的权衡,如果由于某种原因您不能或不想使用GUID,则多列自然键是复制场景的更好选择,因为它在本质上是全球唯一的 – 那是,你不需要一个特殊的算法来使其独一无二,它是唯一的定义.这使得很容易推理出分布式架构.
>插入/更新性能.代币键不是免费的.如果您有一组唯一且经常查询的列,则需要在这些列上创建一个覆盖索引;索引最终几乎与表格一样大,这浪费了空间,并要求在每次进行任何修改时更新第二个索引.如果您只能在表上只有一个索引(聚簇索引),则应该执行此操作！

这就是蝙蝠的想法.如果我突然想起别的话,我会更新