【发布时间】:2015-12-20 00:14:41
【问题描述】:
众所周知,在具有聚集索引的列中使用随机值并不是一个好主意,这就是为什么通常不建议将 GUID 用于具有聚集索引的主键的原因。使用 newsequentialid() 函数,我们可以克服大部分困难。
但是,如果您在 Web 服务器场上生成 GUID,所有这些都访问同一个数据库,会发生什么情况?如本文所述,我正在使用 UuidCreateSequential 在 .NET 代码中创建顺序 ID: http://blogs.msdn.com/b/dbrowne/archive/2012/07/03/how-to-generate-sequential-guids-for-sql-server-in-net.aspx
问题在于,虽然生成的 GUID 在单台机器上是连续的,但在多台机器上却不是这样。因为最重要的 11 个字节(根据 SQL Server)似乎在同一台机器上几乎保持不变,所以它有效地按机器排序,然后按时间排序,而不是期望的相反。
重新排序 GUID 中的字节以在机器之间获得近乎顺序的 GUID 是否值得且可行,或者我应该放弃并使索引非集群化吗?
谢谢!
【问题讨论】:
-
Any 基于 GUID 的聚集索引(主键或其他)是一个坏主意,原因正是您在此处概述的原因。仅仅为了维护一个半任意的排序顺序而创建额外的工作对我来说似乎是一种浪费。为什么不直接建立一个更明智的聚集索引?
-
如果您只是要使用顺序 GUID,为什么还要打扰它们呢?它们占用了大量存储空间,现在它们完全可以预测和重复。
-
@SeanLange:原因是从代码中控制ID,这很方便/实用,尤其是在基于DDD的架构中。
-
@alroc:我认为维护基于主 GUID 键的聚集索引可能会带来一些性能优势,如果这些键按自然顺序排列(即相关行可能靠得很近)
-
适合集群键的候选者是小的、唯一的和单调的。我猜三分之一的人还不错。 ;) 如果您一心想要使用 GUID,您可以让它们成为非集群主键,而沼泽标准标识列成为您的集群键。
标签: sql-server guid uuid clustered-index newsequentialid