多字段主键或“人为”“半人工”键的性能

这不是关于在任何给定表中使用人工自动增量键与使用多字段“主键”的好处或其他方面的问题。任何想要搜索它们的人都可以轻松找到该讨论（或论点）并做出决定。

这个问题更多的是关于键的性能（或缺少键）

我是一名数据库管理员，当我创建表时，我尝试为表使用“自然”键。通常这是一组 2,3，有时是 4 个字段，它们充当给定表的主键。通常这些字段本质上是 Varchar，但很短（最多 10 或 15 个字符）。就我个人而言，我尽量让它们更短！

我的问题是这个。

想象一下，我有一个包含人口统计数据的表格。我可以确保我在每一行中具有唯一性的唯一方法是使用 FirstName FamilyName DateOfBirth PlaceOfBirth 的字段

（您可能想知道为什么我包含“出生地”，我知道另一个人（曾经住在附近 - 相同的电话号码，不同的拨号代码）与我分享了所有这些详细信息（我假设 PlaceOfBirth 不同，但我想我可以使用 MothersMaidenName ;) )

所以现在我有一个有趣的问题。

我可以使用一个更短的字段，它是通过连接 4 个主要字段中的信息创建的，例如： DateOfBirth First 2 characters of FirstName first 2 characters of FamilyName first 2 character of PlaceOfBirth

我的问题是这个。

与直接使用字段（即有多少列）相比，字段的连接在什么时候会提供性能改进。

我从搜索中知道，大多数 DBMS 都有一个“理论上的最大大小限制”，具体取决于创建的 B-Tree。我假设我在主键的长度/大小方面没有达到这个限制。

我考虑使用这种“人为”键的原因是：连接列中的信息很可能足以识别记录，而无需提取所有主键字段（这对性能更好还是没有？与使用所有 4 个主键字段相比有何不同？）

这显然是一个相当“理论”的问题，但我考虑过在一个最终有 4 个 varchar 字段的表上进行这种连接，很明显，只使用一个缩短版本就可以描述唯一性。显然，首先要努力创建这个领域，但在其他人看来，这种努力是否值得，在什么时候它会变得更有趣。

我已经搜索过这个，但我从来没有发现直接问过这个问题，它作为“自然”或“人工”主键讨论出现。

当然，如果这感觉像是“自然”或“人为”的关键讨论，请随意说出来。我的感觉是，这个“人为”的键会提供两者的优点。有没有人在现实世界的解决方案中使用过这个想法？

提前感谢您的想法。

大卫

编辑。我刚找到这个线程

https://stackoverflow.com/questions/3735390/best-primary-key-for-storing-urls

它似乎涵盖了类似的领域，我必须承认我没有想过将我的列“散列”在一起（主要是因为它们本质上很短），但我确实喜欢这个想法。我想你可以这样做并散列整行！

编辑2。

我回到这个问题只是想看看答案是否有任何变化或额外的评论。我已决定接受回复，但想指出，我发现所有回复对讨论条款都有帮助。