是使用 Guid (UniqueIdentifier) 作为主键/代理键列还是序列化的“身份”整数列更好； 为什么更好？在什么情况下你会选择其中一种？
【问题讨论】：
标签： sql sql-server database-design
很少使用 GUID。
为了存储目的而使用主键/代理键。
这也将使人类与数据的交互更容易。
创建索引也会更有效率。
见
【讨论】：
在需要保证唯一性的复制系统中使用 GUID。
在您拥有非复制数据库并且希望最大化性能的情况下使用整数。
【讨论】：
如果您认为您将需要使用数据库之外的数据（即其他数据库），请使用 GUID。有些人会争辩说，情况总是如此，但这是一个判断电话。
【讨论】：
这是一个经常争论的话题，但出于几个原因，我倾向于更倾向于身份。首先，一个整数只有 4 个字节，而一个 16 字节的 GUID。这意味着更窄的索引和更高效的查询。其次，我们在存储过程等中大量使用了@@IDENTITY 和SCOPE_IDENTITY，它们通过GUID 显示在窗口之外。
这是一个不错的小article by Jeff Atwood。
【讨论】：
我个人将 INT IDENTITY 用于我的大部分主键和集群键。
您需要将 主键 分开，这是一个逻辑结构 - 它唯一地标识您的行，它必须是唯一且稳定的并且不是 NULL。 GUID 也适用于主键 - 因为它保证是唯一的。如果您使用 SQL Server 复制，则将 GUID 作为主键是一个不错的选择，因为在这种情况下，无论如何您都需要一个唯一标识 GUID 列。
SQL Server 中的clustering key 是一种物理构造，用于对数据进行物理排序，要正确处理要困难得多。通常，SQL Server 上的索引女王 Kimberly Tripp 还需要一个良好的集群键，它必须是唯一的、稳定的、尽可能窄的，并且理想情况下是不断增长的（INT IDENTITY 就是这样）。
在此处查看她关于索引的文章：
GUID 对于集群键来说是一个非常糟糕的选择，因为它很宽、完全随机，因此会导致索引碎片和性能不佳。此外，集群键行也存储在每个非集群（附加）索引的每个条目中，因此您真的希望保持较小 - GUID 为 16 字节，而 INT 为 4 字节，并且有几个非聚集索引和几百万行，这会产生巨大的差异。
在 SQL Server 中，默认情况下，您的主键是您的集群键 - 但并非必须如此。您可以轻松地将 GUID 用作非集群主键，并将 INT IDENTITY 用作集群键 - 只需稍加了解即可。
【讨论】：
INT 列可以轻松地从 -20 亿一直到 +20 亿 - 没有问题，完全没有问题，即使是负数 - INT 是INT 是 INT - 正面或负面没有任何区别
对此没有唯一的答案。人们很快就使用 Guid 的问题（它们的随机性与主键的 默认 行为相结合也充当集群键）可以轻松缓解。 Guid 的范围比整数更大，但是当您开始用值填充该范围时，就会增加发生冲突的风险。
当您有一个分布式系统（例如，复制的数据库）时，Guid 非常有用，其中大量工作必须进入不会导致系统各部分之间发生冲突的密钥生成机制.同样，整数很有用，因为它们易于使用（每种语言都有整数类型，并非每种语言都有 Guid 类型）并且可以是顺序的（Guid 也可以，但这不是它们的意图使用）。
这完全取决于您要存储什么以及如何存储。那些说“永远不要使用 Guid 的人！”只是在传播 FUD，但它们也不是所有问题的答案。
【讨论】：
在考虑使用整数时，请务必考虑可能出现的最大可能值。由于删除，您经常会得到跳过的数字，因此实际的最大 ID 可能远大于表中的记录总数。
例如，如果您不确定 32 位整数是否可行，请使用 64 位整数。
您可能还会发现这些其他 SO 讨论很有用：
How do you like your primary keys?
What’s the best practice for Primary Keys in tables?
Picking the best primary key + numbering system.
如果您在 SO 中搜索“主键”，您会发现这些以及更多非常有用的讨论。
【讨论】：
我相信它几乎总是一个序列化的身份整数，但有些人会不同意。视情况而定。
身份的原因是效率和简单性。它更小。更容易被索引。它使一个伟大的聚集索引。随着新记录的有序保存，碎片更少。非常适合连接索引。观察数据库中的记录时更容易。
在某些情况下，向导肯定有一席之地。当合并不同的数据时，或者当必须在某些地方创建记录时。向导应该在您的技巧包中，但通常不会是您的首选。
【讨论】：