sql-server - 使用字符数据表示 GUID 主键的反模式有多常见？

Question

我最近在考虑将 GUID 作为主键，并被提醒我曾经遇到过的最严重的滥用它们:

这个数据库包含很多 Entity-Detail 父子关系，比如 Receipt，它有 LineItems。大多数详细信息表(在本例中为 LineItem)使用 GUID 主键。但不是使用 MSSQL 的 uniqueidentifier 存储类型，它们被存储为 38 个字符的字符串，格式为 '{00000000-0000-0000-0000-000000000000}' .哦，他们几乎总是在 nvarchar (Unicode) 列，以 76 个字节为单位(而不是 16 个字节用于唯一标识符)。

这些领域多久加入一次？在系统中的几乎每一个查询中。数百个客户数据库，数百万条符合此配置文件的记录。坏的。

在我的内存中，当引入唯一标识符时，系统并没有出现在 SQL Server 7.0 之前。导致这个问题的只是知识/研究的彻底失败。

我有两个问题:

根据您的经验，这种反模式有多普遍？

很明显，一个 76 字节的 Unicode 字符串的连接比一个 16 字节的二进制数的连接慢得多，不管有没有索引。但是任何人都可以提供一个关于这可能带来的性能影响的想法吗？假设您在任一场景中为连接列编制索引。

Answer 1

我认为问题不在于加入 76 字节 key 和 16 字节 key 之间的固有速度差异，而是更多:

您可以在每个 8k 页面中打包多少行(在这些页面中拆分更多/碎片索引更多/性能更差)......

另外——你没有提到那些假装的 GUID 是否是连续的。如果它们是主键的一部分并且该 KEY 是集群的，那么每个插入都可能重新组织表的完整 btree ......

此外，您在表上拥有的任何非聚集索引都包含主键(因此它们可以对非聚集索引 100% 不满意的查询进行查找)。因此，您的非聚集索引将比它们在具有 UNIQUEIDENTIFIER 类型的表上时大得多。

在我工作过的任何公司中，我都没有看到将 GUID 建模为字符串，但我看到了一些 pk 聚集的表，并且没有特别的原因选择了 GUID。适用于小型数据集，然后......生产中的性能问题。