SQL Server UNIQUEIDENTIFIER作为普通列？

Question

我刚刚遇到了这个问题Using GUID/Uniqueidentifier，并且一个答案here指向article，它基本上讨论了将GUID用作主键的错误。

但是，我想在我的表中使用uniqueidentifiers作为普通列，而不是PK，这样通过api的查询可能会被混淆，而不是人们可以轻易猜测和播放我的数据。因此，在查询记录时，请说

www.domain.com/api/v3/device/component/6F9619FF-8B86-D011-B42D-00C04FC964FF

代码：

SELECT * 
FROM myTable
WHERE guid = '6F9619FF-8B86-D011-B42D-00C04FC964FF'

我可以使用它，而不是int / bigint identity col。

这是一种不好的方法吗？使用这种方法的开销可能是多少？还是有其他选择吗？我的数据库的某些表可能非常大，每10-15秒有数百条记录。

最好的方法是什么？

Answer 1

主键唯一标识一行：它是群集的还是非群集的

因此，GUID可以是主键，没有问题如果它是非群集的。 或者它可以是另一个非群集唯一索引的唯一键。

访问模式

假设您有一个int标识列作为聚簇索引 然后这将做两个表触摸

SELECT * FROM myTable WHERE guid='6F9619FF-8B86-D011-B42D-00C04FC964FF'

索引上的一个用guid作为获取群集密钥的关键。然后另一个触摸聚集索引。这是一个关键的＆＃34;查找，有时可能很昂贵。

您可以通过在基于guid的非聚集索引上使用INCLUDE来缓解此问题

碎片

您还可以使用NEWSEQUENTIALID缓解GUID碎片问题，该断点提供严格单调递增的GUID值。

如果您有一个良好的维护窗口，您可以每晚使用GUID群集密钥对表进行碎片整理。

宽度

群集时GUID（16字节）的宽度会影响所有非群集索引。如果您期望使用GUID的多个索引或子表，这很重要。

总结：这通常很糟糕，但这并不总是重要的

请注意，我们使用GUID的方式与您为我们网站规划的方式相同，并且负载要大得多。 GUID列是非群集的