表中的主键选择什么？答案

【问题标题】：what to choose for primary key in table?表中的主键选择什么？
【发布时间】：2012-02-29 18:31:46
【问题描述】：

我有一个包含数百万条记录的巨大表，假设我的自然键太大并且将来可能会更改，我想添加一个代理主键，并将该代理用作不同表中的外键。

我应该将我的自然键也作为主键吗？还是应该和其他专栏一样？

该表的大部分访问是通过自然键搜索

为了时间性能，应该删除自然键还是将其定义为备用键？
我不想拥有 2 个相同的自然键，应该如何通过使用自然键作为主键来强制执行？
如果我使用自然键作为主键并添加另一个代理键并将其也定义为主键，这意味着什么？我尝试搜索示例确实可以找到一个很好的示例，链接/示例也确实会有所帮助。

【问题讨论】：

“假设我的自然键太大”——也许你的假设不正确，所以请提供更多细节。 “未来可能会改变”——稳定性是一把好钥匙的属性；不变性是理想的，但不是先决条件。但是可能会改变吗？ YAGNI.

标签： sql database

【解决方案1】：

我的建议是创建一个简单的 INT 数据类型主键，如果您使用 MySQL，则将其设为 AUTO_INCREMENT，如果您使用 MS SQL Server，则将其设为 IDENTITY；如果您使用 Oracle，则将其设为 SEQUENCE。如果您需要性能，主键的INT 数据类型非常好。

自然键应该是索引列以便更好地搜索。

【讨论】：

如何使某些列被索引？这将如何强制我的我没有要复制的自然密钥？
例如，如果您使用 MySQL，您可以通过以下方式创建简单索引：CREATE INDEX index_name ON table_name(column_name)
我建议自然键上的索引应该是唯一索引，而不是重复索引。
是的，同意这将是：CREATE UNIQUE INDEX index_name ON table_name(column_name)

【解决方案2】：

最好的方法是使用数据库生成的唯一键（例如 MySQL 中的 AUTO_INCREMENT 和其他 RDBMS 中的同级键）并创建一个由该键和您的自然键组成的组合主键。

让我解释一下原因：

自然键作为辅助唯一键有一个很大的缺点是创建非常糟糕的键本地化：顺序键值往往分布在整个磁盘上，使您的键缓存的使用效率非常低（无论它是如何实现的，概念成立）。自动增量键往往几乎完全本地化，即磁盘上的单个页面，转换为单个磁盘查找，很可能包含更大的键空间部分。

通过将“数据库自然”键与“应用程序自然”键（按此顺序！！）组合成一个组合主键，您可以两全其美。如果自然密钥由一些随机因素（例如 GUID）组成，则尤其如此。

【讨论】：

当我将它们组合为主键时，是否会强制我没有重复的自然键？，你在这个序列中是什么意思？
相反 - 如果您将代理键与自然键组合作为主键，只要代理键具有不同的值，您就可以拥有自然键的副本。 Muhammad 的方法要好得多，只要您使用 unique 索引作为自然键。
1.) 不，它不会，但没有什么能阻止您在自然键上创建辅助唯一键 2.) 要保持密钥局部性，您需要创建 PRIMARY KEY(dbkey,naturalkey)而不是 UNIQUE KEY(naturalkey, dbkey)