我知道这个主题可能已经讨论过几次，但是对此有不同的看法。我的情况是我创建了一个数据库，该数据库将填充40亿条记录，并且每年将添加1到200万条记录。
[我们在美国和欧洲拥有服务器，并且我们进行数据库复制以使它们在这些服务器上保持相似，例如与Facebook在复制中所做的相同。
我的问题是这是表的主键，我应该使用什么-BigInt或Uniqueidentifier，或者对于复制所用的内容没有什么区别？
uniqueidentifier主键，然后添加另一个群集的bigInt列吗？或
bigint主键吗？毫无疑问，请使用Uniqueidentifier。
不需要添加bigint列，您不需要它。
如果您使用合并复制，但没有唯一标识符，则服务器仍将添加该列。
通过使用GUID，您现在可以设置多主数据库架构。如果使用bigint作为标识字段，则要么强迫自己仅使用一个主服务器（以控制bigint），要么必须提出一种防止多个服务器相互冲突的方案。此外，通过使用GUID，您可以摆脱可猜测的ID的困扰-这通常是一件好事。
我自己在亿万个记录范围内的测试（添加/删除了数百万个daily）显示，使用GUID和int作为id时，性能没有下降。
最后注释-调用Web服务时，或者如果要在任何地方显示guid时，大多数地方base64都会对guid进行编码-例如在地址栏中。
我会争论另一种选择：我会尝试AVOID uniqueidentifier列-MOST DEFINITELYLY作为您的聚簇键！
群集键是SQL Server中的最复制的数据结构-包含数百万行，如果您的群集键的大小为8或16字节，它的确会产生huge差异。更不用说uniqueidentifier集群键会引入的页面拆分数-您可以完全避免使用BIGINT类型的集群键。
如果您真的有兴趣-您必须阅读来自Kimberly Tripp的所有这些文章-SQL Server空间中的“索引女王”-清楚地显示了GUID在群集方面的糟糕程度和适得其反关键可以是：