SQL Server 唯一标识符与整数答案

【问题标题】：SQL Server Unique Identitifier vs IntegerSQL Server 唯一标识符与整数
【发布时间】：2011-03-26 08:02:33
【问题描述】：

我一直在学习 ASP.net，并且一直在使用会员系统。当它自动生成表格时，我很惊讶地看到它使用一个名为“uniqueIdentifier”的字段类型作为主键，而多年来我一直使用整数字段设置为自动递增的标识。

这两种方法之间有什么区别（如果有的话），为什么 .NET 似乎偏爱唯一标识符字段？

感谢您提供任何信息！

汤姆

【问题讨论】：

【解决方案1】：

我会说 .NET 不支持将 uniqueidentifier 或 guid 作为 id，但这个特定的实现（ASP.NET SQL Server 成员资格提供程序）却支持。我怀疑那些开发数据库的人假设数据库的使用不是用于高流量站点，或者可能需要进行大量报告的地方。

也许他们试图避免在集成到现有应用程序时出现任何问题，或者在未来的场景中，您的应用程序有一个用户密钥。这可以是任何实体（PK、UserNumber 等）的任何类型的密钥。在 ASP.NET SQL Server 实现中，发生冲突的可能性非常低/接近于零。

我了解到的一个缺点是，在 guid 上具有聚集索引无法扩展到大容量数据库。

我主要是在整数作为 PK 阵营中。它们很小，只使用很少的字节，并且在您的数据库需要扩展时工作得很好。

【讨论】：

【解决方案2】：

有什么区别（如果有的话）这两种方法之间

对于一个唯一标识符是 16 个字节，而一个 int 是 4 个字节。如果你有一个像

这样的 URL

你可以很容易地猜出别人的用户 ID 是什么，所以你可以尝试 2 或 4 等等等等

当您将其作为用户 ID C7478034-BB60-4F5A-BE51-72AAE5A96640 时，它并不容易，并且 uniqueidentifiers 应该在所有计算机上都是唯一的

如果他们使用NEWID() 而不是NEWSEQUENTIALID()，那么他们会出现碎片和页面拆分，请查看Best Practice: Do not cluster on UniqueIdentifier when you use NewId

【讨论】：

如果软件允许通过猜测 ID 进行攻击，那么软件中有一个明显的缺陷，使用更模糊的 ID 来防止这种攻击实际上并不能解决问题，尽管它是有趣的一点我从来没有想过。我认为对于可添加书签的页面（例如产品描述页面），一个简单的 ID=x 比一个大字符串更容易记住和“更好看”。使用整数时，我也很少用完索引，但是当我拥有时，将索引转换为 bigint 真的很容易。

【解决方案3】：

uniqueidentifier类型是SQL的Guid类型（对应的BCL类型是System.Guid）。从概念上讲，Guids 代表一个随机的 128 位数字，应该是唯一的。

虽然 Guid 有其批评者（严格来说，比较 guid 比比较整数稍慢），但它们的随机性使它们在复制等环境中很有帮助，在这种环境中使用递增键可能很困难。

【讨论】：