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

#1 楼

GUID似乎是您的主键的自然选择-如果确实需要，您可能会争辩说将其用于表的PRIMARY KEY。我强烈建议您不要使用GUID列作为群集键，默认情况下，SQL Server会使用该列，除非您明确告知不要这样做。 ：


主键是一种逻辑结构-候选键之一，可唯一且可靠地标识表中的每一行。实际上，这可以是任何东西-INT，GUID和字符串-选择最适合您的情况的东西。是与物理存储相关的事情，在这里，小的，稳定，不断增长的数据类型是您的最佳选择-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-只是在一个表上！多想一想-金伯利·特里普（Kimberly Tripp）的优秀著作-读它，再读一次，消化它！确实，这是SQL Server索引的福音。


GUID作为PRIMARY KEY和/或聚集键
聚集索引的争论还在继续
每个群集的键不断增加聚集索引辩论...........再次！
磁盘空间很便宜-这不是重点！

PS：当然，如果您只处理一个几百行或几千行-这些参数中的大多数对您没有太大影响。但是：如果进入数万或数十万行，或者开始数以百万计，那么这些要点就变得非常关键，也非常重要。

更新：如果您想拥有自己的PKGUID列作为主键（而不是集群键），另一列MYINT（INT IDENTITY）作为集群键-使用此：
必须明确告诉PRIMARY KEY约束它是NONCLUSTERED（否则默认情况下将其创建为聚簇索引）-然后创建第二个索引，定义为CLUSTERED这将起作用-如果您需要对现有系统进行“重新设计”以提高性能，那么这是一个有效的选择。对于新系统，如果您是从头开始的，并且您不在复制场景中，那么我总是选择ID INT IDENTITY(1,1)作为我的集群主键-比其他任何东西都效率更高！

#2 楼

自2005年以来，我一直将GUID用作PK。在这个分布式数据库世界中，这绝对是合并分布式数据的最佳方法。您可以解雇合并表，而不必担心合并表之间的整数匹配。 GUID联接可以轻松复制。

这是我使用GUID的设置：


PK = GUID。 GUID的索引类似于字符串，因此高行表（超过5000万条记录）可能需要表分区或其他性能技术。 SQL Server变得异常高效，因此对性能的关注越来越少。
PK Guid是非聚集索引。除非它是NewSequentialID，否则切勿对GUID进行索引。但是即使这样，服务器重新启动也会导致顺序上的重大中断。
将ClusterID Int添加到每个表中。这是对您的表进行排序的聚集索引。如果要获得最佳性能，请使用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)

#3 楼

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

我所有的类（表）以及一个int PK和FK。类型为Guid（由c＃构造函数生成），上面带有非聚集索引。与Guids配合使用。

#4 楼

如果您使用GUID作为主键并创建聚簇索引，那么我建议为其使用默认值NEWSEQUENTIALID（）

#5 楼

该链接比我说的更好，可以帮助我做出决策。我通常选择int作为主键，除非我有特殊需要，并且我还让SQL Server自动生成/维护该字段，除非有特殊原因。实际上，需要根据您的特定应用确定性能问题。这里有许多因素在起作用，包括但不限于预期的数据库大小，正确的索引编制，有效的查询等等。尽管人们可能会不同意，但我认为在许多情况下您不会注意到这两种选择的不同，您应该选择更适合您的应用程序的内容，以及允许您更轻松，更快，更有效地开发的内容（如果您从未完成过该应用程序其余的有什么不同:)。 -for-my-primary-key.html

PS我不确定您为什么要使用复合PK或您认为可以给您带来什么好处。

#6 楼

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

https://www.sqlskills.com/blogs/kimberly/disk-space-is-cheap/
https://www.sqlskills.com/blogs/kimberly/guids -作为主键和/或群集键/

#7 楼

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