使用 GUID 作为主键的最佳做法是什么，特别是关于性能

Question

我有一个应用程序，该应用程序在几乎所有表中都使用 GUID 作为主键，并且我读到使用 GUID 作为主键时存在性能问题。老实说，我没有看到任何问题，但我即将启动一个新的应用程序，我仍然想使用 GUID 作为主键，但我正在考虑使用复合主键（GUID 和另一个字段。

我之所以使用 GUID，是因为当您具有不同的环境（例如"生产"、"测试"和"开发"数据库）以及数据库之间的迁移数据时，它们很好且易于管理。

我将使用实体框架 4.3，并且我想在应用程序代码中分配 Guid，然后再将其插入数据库。（即我不想让 SQL 生成 Guid）。

创建基于 GUID 的主键的最佳做法是什么，以避免与此方法关联的假定性能影响？

Answer 1

GUID 似乎是主键的自然选择 - 如果您真的必须这样做，您可能会争辩说将其用于表的主键。我强烈建议不要使用 GUID 列作为群集键，SQL Server 默认使用，除非您明确告诉它不要这样做。

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

1. 主键是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这可以是任何东西，真的 - 一个INT，一个GUID，一个字符串 - 选择对你的方案最有意义的内容。

2. 聚簇键（定义表上"聚集索引"的一个或多个列） - 这是一个与物理存储相关的东西，在这里，一个小的、稳定的、不断增加的数据类型是你最好的选择 - INT或BIGINT作为你的默认选项。

默认情况下，SQL Server 表上的主键也用作群集键 - 但不需要这样！我个人在将以前基于 GUID 的主/群集密钥分解为两个单独的键时看到了巨大的性能提升 - GUID 上的主（逻辑）键和单独INT IDENTITY(1,1)列上的群集（排序）键。

正如索引女王金伯利·特里普（Kimberly Tripp）和其他人多次说过的那样，聚类键GUID不是最佳的，因为它的随机性，它会导致大量的页面和索引碎片，以及通常糟糕的性能。

是的，我知道 - SQL Server 2005 及更高版本中有newsequentialid() - 但即使这样也不是真正和完全顺序的，因此也会遇到与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 - 这只是在一张桌子上！

更多值得深思的东西 - 金伯利特里普的优秀东西 - 阅读它，再读一遍，消化它！这是SQL Server索引的福音，真的。

• GUID 作为主键和/或群集键
• 聚簇指数争论仍在继续
• 不断增加的聚类关键——聚类索引辩论......再！
• 磁盘空间很便宜 - 这不是重点！

PS：当然，如果你只处理几百或几千行 - 这些论点中的大多数都不会对你产生太大影响。但是：如果你进入数万或数十万行，或者你开始以百万为单位计算 - 那么这些点变得非常关键，理解起来非常重要。

更新：如果要将PKGUID列作为主键（但不是群集键），将另一列MYINT（ INT IDENTITY ）作为群集键 - 请使用以下命令：

CREATE TABLE dbo.MyTable
(PKGUID UNIQUEIDENTIFIER NOT NULL,
 MyINT INT IDENTITY(1,1) NOT NULL,
 .... add more columns as needed ...... )
ALTER TABLE dbo.MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY NONCLUSTERED (PKGUID)
CREATE UNIQUE CLUSTERED INDEX CIX_MyTable ON dbo.MyTable(MyINT)

基本上：你只需要显式告诉PRIMARY KEY约束它是NONCLUSTERED的（否则默认情况下它会创建为聚簇索引） - 然后你创建一个定义为CLUSTERED

这将起作用 - 如果您有一个需要"重新设计"以提高性能的现有系统，这是一个有效的选择。对于新系统，如果您从头开始，并且您不在复制方案中，那么我总是会选择ID INT IDENTITY(1,1)作为我的集群主键 - 比其他任何事情都高效得多！

Answer 2

自 2005 年以来，我一直使用 GUID 作为 PK。在这个分布式数据库世界中，它绝对是合并分布式数据的最佳方式。您可以触发并忘记合并表，而无需担心联接表之间的整数匹配。可以毫无后顾之忧地复制 GUID 联接。

这是我使用 GUID 的设置：

1. PK = GUID。GUID 的索引类似于字符串，因此高行表（超过 5000 万条记录）可能需要表分区或其他性能技术。SQL Server变得非常高效，因此性能问题越来越不适用。

2. PK Guid 是非聚集索引。切勿对 GUID 进行群集索引，除非它是 NewSequentialID。但即便如此，服务器重新启动也会导致排序严重中断。

3. 将群集 ID 国际添加到每个表。这是您的聚集索引...订购您的桌子。

4. 联接群集 ID （int） 效率更高，但我处理 20-3000 万个记录表，因此联接 GUID 不会明显影响性能。如果您想要最大的性能，请使用 ClusterID 概念作为主键并加入 ClusterID。

这是我的电子邮件表...

CREATE TABLE [Core].[Email] (
    [EmailID]      UNIQUEIDENTIFIER CONSTRAINT [DF_Email_EmailID] DEFAULT (newsequentialid()) NOT NULL,        
    [EmailAddress] NVARCHAR (50)    CONSTRAINT [DF_Email_EmailAddress] DEFAULT ('') NOT NULL,        
    [CreatedDate]  DATETIME         CONSTRAINT [DF_Email_CreatedDate] DEFAULT (getutcdate()) NOT NULL,      
    [ClusterID] INT NOT NULL IDENTITY,
    CONSTRAINT [PK_Email] PRIMARY KEY NonCLUSTERED ([EmailID] ASC)
);
GO
CREATE UNIQUE CLUSTERED INDEX [IX_Email_ClusterID] ON [Core].[Email] ([ClusterID])
GO
CREATE UNIQUE NONCLUSTERED INDEX [IX_Email_EmailAddress] ON [Core].[Email] ([EmailAddress] Asc)

Answer 3

我目前正在使用 EF Core 开发一个 Web 应用程序，这是我使用的模式：

我所有的类（表）都有一个int PK和FK。然后，我有一列类型的 Guid（由 C# 构造函数生成），上面有一个非聚集索引。

EF 中表的所有联接都通过 int 键进行管理，而来自外部（控制器）的所有访问都通过 Guid s 完成。

该解决方案允许不在 URL 上显示int键，但保持模型整洁快速。

Answer 4

这个链接比我说得更好，并有助于我的决策。 我通常选择 int 作为主键，除非我有特定的需要，并且我也让 SQL Server 自动生成/维护此字段，除非我有一些特定的原因不这样做。 实际上，需要根据您的特定应用确定性能问题。 这里有许多因素在起作用，包括但不限于预期的数据库大小、适当的索引、高效的查询等。 尽管人们可能不同意，但我认为在许多情况下，您不会注意到任何选项的区别，您应该选择更适合您的应用程序以及允许您更轻松、更快、更有效地开发的内容（如果您从未完成应用程序，其余的有什么不同:)。

https://web.archive.org/web/20120812080710/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

附言我不确定你为什么要使用复合PK，或者你认为这会给你带来什么好处。

Answer 5

好吧，如果你的数据永远不会达到数百万行，那么你很好。如果你问我，我从不使用 GUID 作为任何类型的数据库标识列，包括 PK，即使你强迫我用霰弹枪在头上设计。

使用 GUID 作为主键是一个明确的缩放限制因素，也是一个关键限制因素。我建议您检查数据库标识和序列选项。序列与表无关，可以根据您的需求提供解决方案（MS SQL具有序列）。

如果您的表开始最多达到数千万行，例如 5000 万行，您将无法在可接受的时间读取/写入信息，甚至标准的数据库索引维护也变得不可能。

然后，您需要使用分区，并且可以扩展到五亿甚至 1-20 亿行。在途中添加分区并不是最容易的事情，所有读/写语句都必须包含分区列（完整的应用程序更改！

这些数字当然（5000万和5亿）是用于轻型选择用途。如果您需要以复杂的方式选择信息和/或有大量插入/更新/删除，对于要求非常苛刻的系统，这些甚至可能是 1-2 百万和 50 百万。如果还添加诸如完整恢复模式、高可用性和无维护窗口等因素（现代系统很常见），事情就会变得非常丑陋。

请注意，此时 20 亿是看起来很糟糕的 int 限制，但 int 小 4 倍，并且是顺序类型的数据，小尺寸和顺序类型是数据库可扩展性的 #1 因素。你可以使用大int，它只是小两倍，但仍然是顺序的，顺序是真正致命的重要 - 甚至比大小更重要 - 当涉及到数百万或几十亿行时。

如果 GUID 也是群集的，情况会更糟。只需插入一行，实际上就会随机存储在物理位置的任何地方。

即使只是一列，也不是PK或PK部分，只是索引它也很麻烦。从碎片化的角度来看。

拥有 guid 列就像任何 varchar 列一样完全可以，只要您不将其用作 PK 部分，并且通常不将其用作连接表的关键列。数据库必须有自己的 PK 元素，使用它们筛选和联接数据 - 之后也可以通过 GUID 进行筛选。

Answer 6

拥有连续的 ID 使黑客或数据挖掘者更容易破坏您的网站和数据。 在为网站选择 PK 时请记住这一点。

Answer 7

如果您使用

GUID 作为主键并创建聚集索引，那么我建议使用它使用默认值NEWSEQUENTIALID()值。

Answer 8

不在用户界面中公开 Id 的另一个原因是，竞争对手可以看到您的 ID 在一天或其他时间段内递增，从而推断出您正在做的业务量。

Answer 9

大多数情况下，它不应该用作表的主键，因为它确实影响了数据库的性能。有关 GUID 对性能的影响以及作为主键的有用链接。

1. https://www.sqlskills.com/blogs/kimberly/disk-space-is-cheap/
2. https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/