一段时间以来，我一直在寻找一个更具体的、令人满意的答案，但没有成功。我不知道我是否只是没有找到合适的地方，但这是：
我从一个应用程序中提取数据，然后对其进行操作并将其发送到我自己的服务器。在提取的数据中有一个最初在应用程序数据库中的自动递增标识符。我刚刚检索到的这个标识符的一个例子是955534861。不自动递增主键，只使用我知道的并且将永远保持唯一的值，或者我应该研究代理键等概念，这不是更好、更有效的设计吗？
提前谢谢。
您描述的情况类似于我的主要工作，即维护数据仓库。我们从其他系统获取数据并存储。
发生在我们身上的事情是，这些"其他系统"发生了变化。这导致了"其他系统"的新版本可能会复制以前系统的唯一标识符。我们通过在数据仓库中的记录中添加一些内容来处理这个问题，以确保它的唯一性。它可能是标识源系统的字段，也可能是日期。它从来都不是一个自动生成的数字。
如果这种情况有可能发生在你身上，你可能想扩大你的选择范围。
如果模型中有一个自然键，则无法通过创建代理键来替换。
您只能添加代理密钥并保留现有的自然密钥，这有其优点和缺点，如下所述。
这会有点书呆子气，但请耐心等待：
只要一个键值是唯一的，它就会发挥作用。但对于性能，理想情况下，您希望关键值尽可能短。
GUID是常用的，因为从统计数据来看，它们不太可能重复。但这是以牺牲大小为代价的：它们有128位长，这使得它们比机器字还长。要比较两个GUID（在排序或向下迁移索引的b树时必须重复执行），需要多个处理器来加载和比较值。当缓存到内存中时，它们将消耗更多的内存。
自动递增键值的优点是
- 它们被保证是唯一的。代理索引值只有预测是唯一的
- 因为它们将在其基础数据类型的范围内具有完全的值覆盖，所以可以使用尽可能紧凑的类型。这样可以实现更小的索引和更高效的比较操作
- 因为可以使用尽可能小的类型，所以可以在单个数据库页面上存储更多的索引值，这意味着在搜索或加入该值时更有可能获得缓存命中。这意味着，在其他条件相同的情况下，表现会更好。
- 在大多数数据库中，自动递增键都是在数据库引擎中工作的，因此生成它们的开销非常小。
- 如果对键值使用聚集索引，则新记录插入不太可能需要随机磁盘查找，而更有可能在预读期间读取，因此，如果基于该键进行任何类型的顺序处理或查找，它可能会运行得更快
主键，通常是一个自动递增的ID，也是MySQL用作行标识符的，所以应该单独使用它。如果您需要一个由应用程序生成的辅助密钥用于其他目的，您可能需要将其添加为另一列，并在其上添加UNIQUE索引。
在其他有适当行标识符机制的数据库中，这不是什么问题。