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

Question

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

Answer 1

有利有弊:

本文涵盖了一切.

GUID优点

• 每个表,每个数据库,每个服务器都是唯一的
• 允许轻松合并来自不同数据库的记录
• 允许跨多个服务器轻松分发数据库
• 您可以在任何地方生成ID,而不必往返数据库
• 大多数复制方案无论如何都需要GUID列

GUID缺点

• 它比传统的4字节索引值大4倍; 如果你不小心,这可能会产生严重的性能和存储影响
• 调试很麻烦(其中userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• 生成的GUID应该是部分顺序的以获得最佳性能(例如,SQL 2005上的newsequentialid())并允许使用聚簇索引

Answer 2

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

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

Answer 3

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

Answer 4

如果您需要对大型集合（假设是第 100,000 个）进行连接，那将会很糟糕。去过那里，受苦了。

后来编辑：我还遇到了一个更糟糕的问题（不能称之为“方法”）：将 GUID 存储在 char(36) 列中！！