在MS SQL中使用GUID作为主键是不是一个坏主意？

我们有一个使用UniqueIdentifier作为每个表的主键的系统.我们注意到这是一个坏主意.我已经看过关于这个主题的类似帖子,但我对任何MS SQL性能以及由于这个决定我可能遇到的其他潜在问题感兴趣.

有利有弊:

本文涵盖了一切.

GUID优点

每个表,每个数据库,每个服务器都是唯一的

允许轻松合并来自不同数据库的记录

允许跨多个服务器轻松分发数据库

您可以在任何地方生成ID,而不必往返数据库

大多数复制方案无论如何都需要GUID列

GUID缺点

它比传统的4字节索引值大4倍; 如果你不小心,这可能会产生严重的性能和存储影响

调试很麻烦(其中userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

生成的GUID应该是部分顺序的以获得最佳性能(例如,SQL 2005上的newsequentialid())并允许使用聚簇索引

我上周写了一篇关于这个的文章,其中有一些代码可以告诉你会发生什么:一些简单的代码来显示Newid和Newsequentialid之间的区别

基本上,如果您使用newid()而不是Newsequentialid(),如果您的PK是聚簇索引(默认情况下将是这样),您会得到可怕的页面拆分

就个人而言,我会使用一个int或bigint作为PK,但只需在另一个"Guid"列中输入那些你需要一个不可饶恕的"键"来记录该记录的情况,并在插入行时生成Guid.