使用GUID作为主键的最佳实践是什么，特别是在性能方面？

Question

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

我之所以使用GUID，是因为当您有不同的环境（如“Production”、“Test”和“Dev”数据库）时，以及在数据库之间迁移数据时，它们很好并且易于管理。

我将使用Entity Framework4.3，我想在应用html" target="_blank">程序代码中分配Guid，然后再将其插入数据库。（即我不想让SQL生成Guid）。

创建基于GUID的主键的最佳实践是什么，以避免与此方法相关联的预期性能打击？

Answer 1

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

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

>

主键是一个逻辑构造--唯一可靠地标识表中每一行的候选键之一。这可以是任何东西，真的-一个int、一个GUID、一个对您的场景最有意义的字符串选择。

正如索引女王Kimberly Tripp和其他人多次指出的那样，GUID作为聚类键并不是最佳的，因为由于它的随机性，它会导致大量的页面和索引碎片，并导致总体上的糟糕性能。

是的，我知道--在SQL Server2005及更高版本中有newSequentialID()-但即使它也不是真正的完全顺序的，因此也会遇到与GUID相同的问题--只是稍微不那么突出而已。

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

快速计算-使用int与guid作为主键和群集键：

• 具有1'000'000行的基表(3.8MB vs.15.26MB)
• 6个非聚集索引(22.89MB vs.91.55MB)

总数：25 MB对106 MB--这只是在一张桌子上！

null

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)

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