主键是否必须在我确定并且始终是唯一的时候自动递增？

Question

我已经寻找了一个令人满意的答案，对我的特定问题现在有一段时间更具体，但是有用。不管我是不是在找不错的地方，我都不知道，但是这里有：

我从应用程序中提取数据，然后将其操作并发送到我自己的服务器。拉出的数据中，最初是在应用程序的数据库中，是自动递增的标识符。我刚刚检索到的这个标识符的一个例子是 955534861 。不是更好，更有效的设计，不自动增加我的主键，只使用我知道的值，并将永远保持独特，或者我应该看看代理键等概念？

提前致谢。

Answer 1

您描述的情况类似于维护数据仓库的主要工作。我们从其他系统获取数据并存储它。

发生在我们身上的事情是这些“其他系统”发生了变化。这导致新版本的“其他系统”将复制先前系统中的唯一标识符。我们通过在数据仓库中添加一些内容来确保它的唯一性。它可能是识别源系统的字段，也可能是日期。它永远不是自动生成的数字。

如果您有这种情况发生这种情况，您可能希望扩展您的选择。

Answer 2

如果模型中有自然键，则无法通过创建代理键来替换。

您只能添加代理密钥，并保留现有的自然密钥，这有利有弊，如here所述。

Answer 3

主键（通常是自动递增ID）也是MySQL用作行标识符的，因此它应该保持不变。如果您需要由应用程序为某些其他目的生成的辅助密钥，您可能希望将其添加为另一个具有UNIQUE索引的列。

在其他具有正确行标识符机制的数据库中，这不是问题。

Answer 4

这会变得有点书呆子，但请跟我说：

只要键值是唯一的，它就会发挥其功能。但是对于性能，理想情况下，您希望键值尽可能短。

GUID是常用的，因为它们在统计上极不可能重复。但这是以大小为代价的：它们是128位长，这使得它们比机器字长。要比较两个GUID（必须在排序时重复完成，或者在b树下向下迁移索引），需要多个处理器入口来加载和比较这些值。当缓存到内存中时，它们将消耗更多内存。

自动递增键值的优点是

• 他们保证是唯一的。代理索引值仅预测是唯一的。
• 因为它们将在其基础数据类型的范围内具有完全值覆盖，所以可以使用最紧凑的可能类型。这样可以实现更小的索引和更高效的比较操作
• 因为可以使用尽可能小的类型，所以可以在单个数据库页面上存储更多索引值，这意味着在搜索或加入该值时，您更有可能获得缓存命中。这意味着性能将是 - 所有其他条件相同 - 更好一些。
• 在大多数数据库中，自动递增键都在数据库引擎中工作，因此生成它们的开销非常小。
• 如果对键值使用聚簇索引，则新记录插入不太可能需要随机磁盘搜索，并且更有可能在预读期间读取，因此如果您执行任何类型的顺序基于该密钥处理或查找，它可能会运行得更快。