这个计算的 CHECKSUM() 索引设计有意义吗？

Question

我在我正在处理的 SQL Server 2005 数据库中遇到了在我看来有点奇怪的模式，并且想知道它是否只是我，或者它是否真的很奇怪。

有许多带有uniqueidentifier主键的表，它们也有一个计算列，它是该CHECKSUM键的，例如

[CustomerGuid] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
[CustomerHash]  AS (CHECKSUM([CustomerGuid])) PERSISTED,

然后，有包含这两个字段的索引，例如

CREATE NONCLUSTERED INDEX [IX_Customer_CustomerHashAndGuid] ON [dbo].[Customer] 
(
    [CustomerHash] ASC,
    [CustomerGuid] ASC
)

此模式还会弹出不是主键的 Guid - 例如，每个订单都有一个Order表，CustomerGuid以及CustomerHash这两个列上的索引，用于按客户查找订单。

当然，校验和的全部意义在于您仅在校验和上创建索引，因此 aSELECT将检索与校验和匹配的记录，然后比较基础值作为安全检查？将潜在价值放入指数中不会浪费大量空间而没有真正的收益吗？

Answer 1

你是对的，这是没有意义的。

我认为这是错误的两个（许多）原​​因

• 它不能保证唯一（CHECKSUM 给出 int）而 GUID 是（在 GUID 范围内）。重复的可能性很小，但很有可能：有点像“生日问题”

• 它仍然是随机顺序。IDENTITY 优于聚集索引的 GUID 的主要原因是 IDENTITY 是单调递增的。CHECKSUM(someGUID)也是随机顺序

我会添加一个新的 IDENTITY 列，然后开始更改依赖项以仅使用它。