主键是非常不幸的符号，因为“初级”的内涵和与逻辑模型有关的潜意识联想。 因此我避免使用它。 相反，我指的是物理模型的代理键和逻辑模型的自然键。

重要的是，每个实体的逻辑模型至少具有一组“业务属性”，其包括实体的密钥。 Boyce，Codd，Date等在关系模型中将这些称为候选键。 然后，当我们为这些实体构建表时，它们的候选键在这些表中成为自然键。 只有通过那些自然键，用户才能唯一地识别表中的行; 因为代理键应始终对用户隐藏。 这是因为代理键没有商业意义。

然而，在没有代理键的情况下，我们的表的物理模型在许多情况下效率低下。 回想一下，非聚集索引的非覆盖列只能通过密钥查找(通常)找到聚簇索引(忽略作为堆积实现的表)。 当我们的可用自然密钥很宽时，这(1)扩大了我们的非聚簇叶节点的宽度，增加了存储要求，并且对非聚集索引的搜索和扫描进行了读取访问; (2)减少聚集索引的扇出，增加索引高度和索引大小，再次增加聚簇索引的读取和存储要求; (3)增加了我们的聚簇索引的缓存要求。 从缓存中追逐其他索引和数据。

这是一个小的代理键，被指定为RDBMS作为“主键”证明是有益的。 当设置为聚类键时，为了用于从非聚集索引和相关表中的外键查找中查找聚簇索引的键，所有这些缺点都消失了。 我们的聚簇索引扇出再次增加以减少聚簇索引的高度和大小，减少聚簇索引的缓存负载，减少通过任何机制访问数据时的读取(无论是索引扫描，索引搜索，非聚簇键查找还是外键查找) 并降低表的聚簇索引和非聚簇索引的存储要求。

请注意，仅当代理键很小且聚类键时才会发生这些好处。 如果GUID用作聚类键，则情况通常比使用最小可用自然键时更糟。 如果表被组织为堆，则8字节(堆)RowID将用于键查找，这比16字节GU