SQL Guid主键加入性能

Question

我目前使用的GUID作为NONCLUSTERED PRIMARY KEY旁边的INT IDENTITY列.

GUID必须允许脱机创建数据和同步 - 这是整个数据库的填充方式.

我知道将GUID用作聚簇主键的含义,因此是整数聚簇索引但使用GUID作为主键,因此其他表上的外键具有显着的性能影响？

是否有更好的选择使用整数主/外键,并使用GUID作为UNIQUE INDEX每个表上有一个客户端ID ？ - 我担心的是,实体框架需要加载导航属性才能获得相关实体的GUID,而无需对现有代码进行重大更改.

有问题的数据库/硬件是SQL Azure.

Answer 1

一般来说，主键/外键字段最好使用 INT，无论这些字段是否是聚集索引中的前导字段。这个问题与 JOIN 性能有关，即使您使用 UNIQUEINDENTIFIER 作为 NonClustered，或者即使您使用 NEWSEQUENTIALID() 来减少碎片，随着表变大，它对于 INT 字段之间的 JOIN 的可伸缩性会更高。（请注意，我并不是说PK / FK 字段应始终为 INT，因为有时可以使用完全有效的自然键）。

在您的情况下，考虑到实体框架以及在应用程序中而不是在数据库中生成 GUID，请采用使用 INT 作为 PK / FK 字段的替代建议，而不是在所有表中使用 UNIQUEIDENTIFIER ，而只将它在主用户/客户信息表中。我认为您应该能够根据 GUID 一次性查找客户 INT 标识符，缓存该值，然后将 INT 值用于所有剩余操作。是的，请确保 GUID 字段上有一个唯一的非聚集索引。

总而言之，如果您的表永远不会（我的意思是永远不会，而不是在前两年）每个表的行数可能会超过 100,000 行，那么使用 UNIQUEIDENTIFIER 就不用担心，因为少量的行通常表现良好（给定中等体面的硬件，不会因其他进程而负担过重或内存不足）。显然，由于使用 UNIQUEIDENTIFIER 而导致 JOIN 性能下降的程度在很大程度上取决于系统的具体情况：硬件以及查询类型、查询的编写方式以及系统负载的大小。