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

Question

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

Answer 1

整数加速更快,一个.在处理数百万行时,这一点尤为重要.

对于两个,GUID比整数占用更多的空间.同样,在处理数百万行时非常重要.

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

在这里可以找到更深入的外观,并在Jeff的博客上找到.

Answer 2

从程序员的角度来看GUID很棒 - 它们保证(几乎)是独一无二的,所以为什么不在任何地方使用它们,对吧？

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

• GUID作为主键(负责唯一标识表中的单行)可能没问题 - 毕竟,它们是唯一的,对吧？
• 但是,SQL Server也有集群密钥的概念,它对表中的数据进行物理排序; 如果您对此不了解,并且未明确执行任何操作,则主键将成为您的群集密钥.

Kimberly Tripp--世界知名的SQL Server索引和性能专家 - 有很多博客文章说明为什么GUID作为你的集群密钥是一个非常糟糕的主意 - 查看她关于索引的博客.

最值得注意的是,她关于群集密钥的最佳做法是:

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

GUID通常是静态且唯一的 - 但它们既不窄(对于INT而言为16字节对4字节),也不会增加.由于它们的性质,它们是独特的和(伪)随机的.

狭窄的部分很重要,因为聚类键将被添加到表的每个非聚集索引的每个索引页面上 - 如果您有几个,并且表中有几百万行,则此数量大量浪费空间 - 不仅在磁盘上,而且在SQL Server的RAM中.

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

总而言之,如果你真的关心你的SQL Server性能,使用GUID作为集群密钥是一个非常糟糕的主意 - 使用INT IDENTITY()代替,可能使用GUID作为主(非集群)密钥,如果你真的要.

渣

Answer 3

1. GUID是int的四倍,是bigint的两倍.

2. 如果您尝试对表进行故障排除,则很难查看GUID.