SQL Server：主键架构主要是 Guid，但有时是整数类型答案

【问题标题】：SQL Server: Primary Key Schema Largely Guid but Sometimes Integer TypesSQL Server：主键架构主要是 Guid，但有时是整数类型
【发布时间】：2010-05-14 17:47:20
【问题描述】：

好吧，这可能是一个愚蠢的问题，但是......

我继承了一个项目，并负责检查主键关系。

该项目主要使用Guids。我说“很大程度上”是因为有些示例表使用整数类型来反映枚举。例如，dbo.MessageFolder 具有 int 类型的 MessageFolderId 来反映

public emum MessageFolderTypes
{
  inbox = 1,
  sent = 2, 
  trash = 3, 
  etc...
}

这种情况经常发生。存在具有 int 类型主键的表，这是不可避免的，因为它们依赖于枚举和具有 Guid 类型的主键的表，这反映了以前程序员的主键选择。

我应该关心 PK 架构像这样参差不齐吗？感觉不对，但真的很重要吗？如果这会造成问题，我该如何解决（如果没有认真的跑腿工作，我真的无法将所有 PK 移动到类型 int 并且我从未听说过具有 guid 值的枚举）？

谢谢。

【问题讨论】：

标签： sql-server types primary-key guid

【解决方案1】：

理想情况下，由于性能原因，您应该将 GUID 改成 PK - 但我知道这可能是不可能的。

GUID 性能在这里得到了很好的展示：What are the performance improvement of Sequential Guid over standard Guid?

我不担心会出现问题，如果您使用最小的键，那么您一定会在数据库中拥有几种不同的数据类型作为 PK (TinyInt/SmallInt/Int/BigInt)。

【讨论】：

+1 虽然该链接并不真正相关 - 它会将 GUID 与增量 (?!?) GUID 进行比较...
@BlueRaja，对不起 - 你是对的！我最近将表从 NewID() 更改为 NewSequentialID() （这是我无法更改的遗留问题）。公平地说，它对 OP 仍然有用，它确实消除了我们在大型插入时的超时 :)

【解决方案2】：

你可以为“速赢”做的是：

保持主键不变（好处：您不需要更改参照完整性约束）
但将您的 GUID 主键设为非聚集主键
将集群键放在单独的字段中 - 如果有有用的字段，请使用已经可用的内容 - 如果没有，请使用 INT IDENTITY 字段

拥有一个良好的集群密钥可以带来非常显着的性能提升！不仅仅是几个百分点，而是几个数量级。

在此处阅读为什么 GUIDs as Primary Key（实际上：作为集群键）是一个非常糟糕的选择，并在此处阅读 The Clustered Index Debate - Again! 一个好的集群键应该是什么样的 - 理想情况下：

窄（尽可能少的字节）
静态（永不改变）
唯一（否则 SQL Server 将需要通过向它们添加 4 个字节来“唯一化”您的条目）
不断增加（以避免昂贵的页面拆分并减少索引/页面碎片）

INT IDENTITY 是理想的候选人。

【讨论】：

【解决方案3】：

最重要的是确保完整性所必需的所有密钥都得到执行。没有真正的理由必须在每个表中使用相同类型的列作为键。大概您还有其他（自然）键由唯一约束/索引强制执行，如果是这样，我希望其中一些包含既不是整数也不是 guid 的列。

【讨论】：