为什么不总是使用GUID而不是整数ID？

Question

使用GUID有什么缺点？ 为什么不总是默认使用它们？

Answer 1

整数加速更快，一个。在处理数百万行时，这一点尤其重要。

对于两个，GUID比整数占用更多的空间。再次，在处理数百万行时非常重要。

对于三个，GUID有时采用不同的格式，可能会导致应用程序中的打嗝等。整数是一个整数，贯穿始终。

可以找到更深入的外观here和Jeff's blog。

Answer 2

GUID从程序员的角度来看很棒 - 它们保证（几乎）是唯一的，所以为什么不在任何地方使用它们，对吧？

如果从DBA角度和数据库角度来看，至少对于SQL Server，需要考虑以下几点：

• GUID作为主键（负责唯一标识表中的单行）可能没问题 - 毕竟，它们是唯一的，对吗？
• 但是，SQL Server也有集群密钥的概念，它对表中的数据进行物理排序;如果您不知道这一点，并且没有明确做任何事情，那么您的主键就会成为您的群集密钥。

Kimberly Tripp--世界知名的SQL Server索引和性能专家 - 有很多关于为什么GUID作为你的群集密钥是个坏主意的博客文章 - 请查看她blog on indexes。

最值得注意的是，她对群集密钥的最佳做法是：

• 窄
• 静态
• 独特
• 不断增加

GUID通常是静态且唯一的 - 但它们既不是狭窄的（16字节而非INT的4字节），也不会增加。由于它们的性质，它们是独特的和（伪）随机的。

狭义部分很重要，因为集群密钥将被添加到表格中每个非聚集索引的每个索引页面上 - 如果你有几个，并且你的表中有几百万行，这相当于浪费了大量空间 - 不仅在磁盘上，而且在SQL Server的RAM中。

不断增加的部分非常重要，因为GUID的随机性会导致索引中的大量碎片，这会对您的性能产​​生负面影响。即使SQL Server 2005及更高版本的newsequentialid()也没有真正创建顺序GUID - 它们会连续一段时间然后再次跳转，导致碎片（少于完全随机的GUID，但仍然如此）。

总而言之，如果您真的关心SQL Server性能，using GUIDs as a clustering key是一个非常糟糕的主意 - 请改用INT IDENTITY（），可能使用GUID作为主要（非群集）关键，如果你真的需要。

马克

Answer 3

1. GUID比int大四倍，是bigint的两倍。

2. 如果您尝试对表格进行问题排查，则很难查看GUID。

Answer 4

GUIDS可以提前简化生成密钥，或者离线生成密钥，或者在群集中生成密钥，而不会发生冲突。可能还有一些安全优势，所有密钥都是不可思议的。

缺点是它更难以阅读/打字，在你的许多桌面上，你可能会在以后意识到需要返回并生成人性化的密钥。它们还会将您的记录均匀地分布在一个表中，这可能会使查询多个记录的速度变慢，这些记录大约在同一时间插入，而不是具有自动编号键，其中您的记录按时间顺序插入。

Answer 5

Kimberly L. Tripp：GUIDs as PRIMARY KEYs and/or the clustering key

您是否阅读了右侧的相关链接？

Answer 6

与整数相比，GUID大而慢 - 所以在需要时使用它们，在不需要时避开它们，就像那样简单！

Answer 7

这个答案并不排除使用INT作为主键的想法。它主要是指出当guid有用时。

这是一篇很棒的（简短的）文章：
http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html

...解释
我将guids用于任何（通用）数据库实体类型，可能需要导出或与另一个数据库实例共享。这样，我就有了一个DNA标记（即guid），可以用来区分同一实体类型的“like”对象。

例如，让我们假设两个数据库实例都有一个名为PROJECT的表。如果两个项目共享相同的名称或编号，则很难区分哪个是哪个。使用GUID虽然您可以轻松区分2个项目及其来源......即使它们之间有许多相似的值。这似乎不可能......但实际上可以而且确实会发生。

Answer 8

您将看到GUID作为主/群集密钥的最大性能影响是在大型表中插入记录。重新编制索引可能是一项繁重的任务，因为您的密钥将落在中间位置

Answer 9

使用GUID作为主键最终会导致数据库崩溃，因为驱动器过于分散。这是一种被称为颠簸的情况。