GUID与INT IDENTITY

Question

可能重复:
您如何看待主键？

我知道使用GUID的好处,以及在数据库中使用和INT作为PK的好处.考虑到GUID本质上是128位INT而普通INT是32位,INT是节省空间(尽管在大多数现代系统中这一点通常没有实际意义).

最后,在什么情况下你会发现自己使用INT作为PK而不是GUID？

Answer 1

Kimberley Tripp(SQLSkills.com)有一篇关于使用GUID作为主键的文章.由于不必要的开销,她建议反对它.

Answer 2

除了在需要同步多个数据库实例时选择不好时,INT还有一个我未提及的缺点:插入总是出现在索引树的一端.当你有一个具有大量移动的表时,这会增加锁争用(因为相同的索引页必须通过并发插入来修改,而GUID将被插入到整个索引中).如果使用B*树或类似的数据结构,则还可能必须更频繁地重新平衡索引.

当然,在进行手动查询和报告构建时,int更容易看到,并且空间消耗可能通过FK使用而增加.

我有兴趣看看SQL Server实际上如何处理具有IDENTITY PK的插入式表的任何测量结果.

Answer 3

回答你的问题:最后,在什么情况下你会发现自己使用INT作为PK而不是GUID？

如果我的系统有离线版本的在线/离线版本,我可以使用GUID,您可以保存数据,并且在同步期间有一天将数据传输回服务器.这样,您确信在数据库中两次不会使用相同的密钥.

Answer 4

INT是节省空间的(虽然这一点在大多数现代系统中通常都没有用).

不是这样.乍一看似乎是这样,但请注意,每个表的主键将在索引中的整个数据库中重复多次,并在其他表中作为外键重复.它几乎涉及任何包含其表的查询 - 当它是用于连接的外键时非常密集.

此外,请记住,现代CPU非常非常快,但RAM速度却没有跟上.因此缓存行为变得越来越重要.获得良好缓存行为的最佳方法是使用较小的数据集.因此,4到16个字节之间看似无关的差异很可能会导致速度明显不同.不一定总是 - 但这是需要考虑的事情.

Answer 5

我们在各种复杂的企业软件中都有Guids.工作顺利.

我相信Guids在语义上更适合作为标识符.在遇到这个问题之前,没有必要担心性​​能问题.注意过早优化.

任何类型的数据库迁移都有一个优点.使用Guids,您将不会发生碰撞.如果您尝试合并使用int用于标识的多个DB,则必须替换它们的值.如果在网址中使用了这些旧值,那么在搜索引擎优化后它们现在会有所不同.

Answer 6

比较主键与外键之间的关系时,INT会更快.如果表格被正确编入索引并且表格很小,那么您可能看不到太慢,但您必须尝试确保.INT也更容易阅读,并与其他人沟通.简单地说,"你能看一下1234的记录吗？" 而不是"你能看看记录031E9502-E283-4F87-9049-CE0E5C76B658吗？"

Answer 7

如果您计划在某个阶段合并数据库，即对于多站点复制类型设置，Guid 将节省很多麻烦。但除此之外，我发现 Int 更容易。

Answer 8

如果数据存在于单个数据库中（就像我们通常编写的应用程序的大多数数据一样），那么我使用IDENTITY. 它很容易，旨在以这种方式使用，不会分割聚集索引并且绰绰有余。有些记录会用完 20 亿条记录（如果使用负值，大约为 40 亿条记录），但无论如何，如果一张表中有这么多记录，那么您将不得不吐槽，然后就会遇到数据仓库问题。

如果数据存在于多个独立的数据库或与第三方服务的接口中，那么我将使用GUID可能已经生成的数据。一个很好的例子是数据库中的 UserProfiles 表，它通过objectGUID分配给他们的 Active Directory 将Active Directory 中的用户映射到应用程序中的用户配置文件。