我最近开始研究一个具有离线场景合并复制的应用程序。我们有一个 int 标识列，用作 pk 和聚类索引。我们在每个表中也有 uniqueidentifier 列，因为复制需要它。在现场，由于身份列，我们有时会遇到身份范围超出 1 个或多个订阅数据库的问题。然后我们的支持人员介入并花费大量时间压缩该表，重新初始化订阅等。为了摆脱这个问题，我看到了 2 个解决方案。1. 使用 BigInt 列而不是 int 并保持身份。这将提供更大的范围，希望我们再也不会看到这个问题。2.去掉identity列，将uniqueidentifier列作为pk和聚簇索引。此列已经填充了 newsequntialID()。这将永久摆脱这个问题。这也将减少表的整体大小，因为从表中删除了 1 列，但它会增加外键索引和其他非聚集索引的大小。
我进行了一些负载测试，虽然 bigint 在时间方面稍有领先，但并没有太大的差异。
您如何看待这两个选项或我没有想到的任何其他选项？