sql - Guid 主键/外键困境 SQL Server

Question

我面临着将主键从 int 身份更改为 Guid 的困境。我会直截了本地提出我的问题。这是一个典型的零售管理应用程序，具有 POS 和后台功能。有大约100张 table 。数据库与其他数据库同步并接收/发送新数据。

大多数表没有频繁的插入、更新或执行选择语句。但是，有些确实有频繁的插入和选择，例如。产品和订单表。

有些表中最多有 4 个外键。如果我将主键从“int”更改为“Guid”，那么在从具有许多外键的表中插入或查询数据时是否会出现性能问题。我知道有人说过索引会碎片化并且 16 字节是一个问题。

在我的情况下，空间不会成为问题，显然也可以使用“NEWSEQUENTIALID()”函数来处理索引碎片。有人可以告诉我，从那里的经验来看，Guid 在具有许多外键的表中是否会出现问题。

我会很感激你对此的想法......

Answer 1

GUID 似乎是您的主键的自然选择 - 如果您真的必须这样做，您可能会争辩说将它用于表的 PRIMARY KEY。我强烈推荐的内容 不做使用 GUID 列作为 聚类 key ，默认情况下 SQL Server 会这样做，除非您明确告诉它不要这样做。

你真的需要把两个问题分开:

1) 主键 是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这可以是任何东西，实际上 - 一个 INT、一个 GUID、一个字符串 - 选择最适合您的场景的内容。

2) 聚类 key (定义表上“聚集索引”的一列或多列)——这是一个与物理存储相关的东西，在这里，一个小的、稳定的、不断增加的数据类型是你最好的选择——INT 或 BIGINT 作为你的默认值选项。

默认情况下，SQL Server 表上的主键也用作集群键 - 但不必如此!当将以前的基于 GUID 的主键/集群键分解为两个单独的键时，我个人看到了巨大的性能提升 - GUID 上的主(逻辑)键和单独的 INT IDENTITY 上的集群(排序)键(1， 1) 列。

如 Kimberly Tripp - 索引女王 - 和其他人已经多次说过 - 作为集群键的 GUID 不是最佳的，因为由于它的随机性，它会导致大量的页面和索引碎片，并且通常会导致性能不佳。

是的，我知道 - 有 newsequentialid()在 SQL Server 2005 及更高版本中 - 但即使这样也不是真正和完全顺序的，因此也遇到与 GUID 相同的问题 - 只是不那么突出。

然后还有另一个问题需要考虑:表上的聚簇键也将添加到表上每个非聚簇索引的每个条目中 - 因此您确实希望确保它尽可能小。通常，对于绝大多数表来说，具有 2+ 十亿行的 INT 应该足够了 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存上节省数百兆字节的存储空间。

快速计算 - 使用 INT 与 GUID 作为主键和集群键:

具有 1'000'000 行的基表(3.8 MB 与 15.26 MB)

6 个非聚集索引(22.89 MB 与 91.55 MB)

总计:25 MB 与 106 MB - 那只是在一张 table 上!

还有一些值得深思的东西——金伯利·特里普 (Kimberly Tripp) 的优秀作品——阅读它，再读一遍，消化它!这是 SQL Server 索引的福音，真的。

GUIDs as PRIMARY KEY and/or clustered key

The clustered index debate continues

Ever-increasing clustering key - the Clustered Index Debate..........again!

所以如果你真的 必须将您的主键更改为 GUID - 尝试确保主键不是集群键，并且您在表上仍然有一个用作集群键的 INT IDENTITY 字段。否则，您的表现肯定会受到重创。