SQL Guid 主键连接性能

Question

我目前将 GUID 用作 NONCLUSTERED PRIMARY KEY 以及 INT IDENTITY 列。

需要 GUID 才能允许脱机创建数据和同步 - 这就是填充整个数据库的方式。

我知道使用 GUID 作为聚集主键(因此使用整数聚集索引)的影响，但是使用 GUID 作为主键以及其他表上的外键是否会对性能产生重大影响？

使用整数主/外键并使用 GUID 作为客户端 ID(每个表上都有 UNIQUE INDEX)是否是更好的选择？ - 我担心 Entity Framework 需要加载导航属性才能获取相关实体的 GUID，而不会对现有代码进行重大更改。

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

Answer 1

您还可以针对唯一键约束创建外键，这样您就可以选择使用 ID 身份的外键作为 Guid 的替代方案。

即

Create Table SomeTable
(
    UUID UNIQUEIDENTIFIER NOT NULL,
    ID INT IDENTITY(1,1) NOT NULL,

    CONSTRAINT PK PRIMARY KEY NONCLUSTERED (UUID),
    CONSTRAINT UQ UNIQUE (ID)
)
GO

Create Table AnotherTable
(
    SomeTableID INT,

    FOREIGN KEY (SomeTableID) REFERENCES SomeTable(ID)
)
GO

编辑

假设您的集中式数据库是一个 Mart，并且仅从源数据库完成批量 ETL，如果您直接对中央数据库进行 ETL(即不通过 Entity Framework )，给定如果您的所有表在从分布式数据库重新填充后都具有 UUID FK，则您需要在 ETL 期间映射 INT UKC 或在导入后修复它们(这需要对 INT FK 执行临时 NOCHECK 约束步骤)。

加载 ETL 并映射 INT 键后，我建议您从 ORM 模型中忽略/删除 UUID - 您需要在 INT 键上重新生成 EF 导航。

如果您直接更新中央数据库或进行连续 ETL 并使用 EF 作为 ETL 本身，则需要不同的解决方案。在这种情况下，只需将 PK GUID 保留为 RI 的 FK，完全删除 INT FK，并选择其他合适的列进行集群(最大限度地减少页面读取)，总 I/O 可能会更少。