增加增量大小以匹配 GUID 优势答案

【问题标题】：Increase increment size to match GUID advantage增加增量大小以匹配 GUID 优势
【发布时间】：2009-10-21 22:53:18
【问题描述】：

我一直在考虑实施这个系统，但不禁觉得某处有问题。使用 GUID 而不是递增 int 的要点之一是，将来，如果您要将数据库合并在一起，您将不会在主键/标识符上发生任何冲突。但是，我的方法是将增量大小设置为 X，其中 X 是我将来很可能拥有的服务器数量。然后，在每个服务器上，让种子比前一个服务器上的种子数增加。这样，在合并过程中，不会与主键发生冲突。这是一种安全、正常的方法还是我疯了:)？谢谢

【问题讨论】：

标签： sql primary-key guid auto-increment

【解决方案1】：

在多主 SQL 复制中，您通常将主键定义为：

GUID
int 的增量大小 > 安装次数
具有固定偏移量的整数

GUID 的缺点是它们更难阅读并且占用更多空间。但是，它允许您扩展到 n 个实例。

整数更容易处理。它们还具有能够轻松判断哪个服务器创建了记录的优势。缺点是您必须预测可能合并的最大数据库数，或者猜测单个实例可能插入的最大行数。

固定偏移的示例是：站点 A 从 0 开始，站点 B 从 1,000,000 开始，站点 C 从 2,000,000 开始。在一个站点插入一百万行之前，此方案运行良好。此方案可能适用于汽车经销商处的汽车，因为任何经销商都不太可能销售超过 1,000,000 辆汽车，并且在应用程序的生命周期内您可能拥有数百家经销商。

【讨论】：

您好 Brianegget，感谢您的回复。我设法跟进“猜测单个实例可能插入的最大行数”。你这是什么意思？

【解决方案2】：

这里让我害怕的是你对“最有可能”的使用。你在这里假设未来，通常这对这样的事情不是一件好事。为什么不使用 GUID？

如果您在原以为拥有的服务器上添加一台额外的服务器会怎样？我可以看到事情很快变得非常复杂。

【讨论】：

嗨，大卫，感谢您的回复。我在几个表上使用 GUID，但出于大小和搜索性能的考虑，我决定不使用它就是一切。据我所知，无法对 GUID 进行排序这一事实会导致查询速度变慢。