Guid为PK低性能

Question

我正面临这个问题：我有一个大约10K行的数据库和一个GUID作为表的PK。当我从数据库中做一些选择时，与int自动增量PK相比，响应“慢”。

我需要GUID能够向我保证的伪随机密钥。

所以，我想知道在数据库中使用新的BIGINT KEY作为PRIMARY KEY和带索引的guid列（它真的需要GUID列上的索引吗？），我的性能会比现在好。

由于

Answer 1

GUID数据类型很可能是主键列的最差候选者之一，主要有两个原因。

1. 这是一个随机值，列值是随机的意味着SQL Server必须在现有行之间的某处插入新行，这会导致大量页面拆分和碎片索引。

2. 它是一个16字节的数据，比Integer数据类型大4倍意味着SQL Server将处理4倍以上的数据，只是为了处理整数值而执行相同的操作。

3. 关于GUID唯一的好处是，它是唯一的，但它是否真的值得支付你为GUID列支付的价格？我会让你决定这个:)

坚持使用Integer作为主键列，使其成为自动生成值的标识。

Answer 2

GUID索引很可能非常破碎。做碎片整理。

GUID索引已群集或非群集将分段。

即使您将GUID移动到非聚簇索引，索引仍会碎片化。经过多次插入后，您将对该索引进行碎片整理。填充因子为50％将减缓碎片。

只需对GUID索引进行常规碎片整理（重建或重新组织） 你可以把它留作PK。

或者您可以使用NEWSEQUENTIALID生成有序GUID。该索引不会与插入片段分段。