我正在开发一个数据库密集型应用程序，它可以维护大约5个表。这些表每个包含数千条记录。所有表都使用GUID群集主键。为了提高效率，我在表之间删除了外键。
我正在运行65000行的脚本，它创建了一大堆表（包括我的表）和存储过程（大约一半的时间花在那里）然后继续向我的表插入大约40000条记录，然后更新大约20000条那些记录。
我的AMD 3.5 Ghz 8核机器需要1:15。
令人惊讶的是，如果我改变这5个表 - 添加BIGINT标识代理主键（查询仍然使用GUID加入） - 将先前的群集GUID主键降级为唯一列
然后它在3:00分钟运行！
将它从BIGINT更改为INT大约1:30！
群集GUID PK如何比自动增量INT快得多，并且比自动增量BIGINT群集PK快得多？
注意：GUID值本身是在代码中生成的，而不是由DB生成的。
查看这个简化的基准脚本，展示我的意思。
答案 0 :(得分：1)
使用您的测试用例，这是预期的。第一个测试只生成一个具有一个字段的表。另外两个构建了两列和两个索引。
这是一个更合适的测试。所有三个测试都有一个GUID字段和一个INT（或BIGINT）字段。所有字段都已编入索引。在UID上使用PK并在UID上使用非聚簇索引的测试表在我的服务器上快2秒。
这是我的测试代码：http://pastebin.com/MFTA3Da1
答案 1 :(得分：-3)
经过大量测试后发现，使用guid pk比使用int代理键和guid自然键更快。
关于因群集和碎片而避免GUID主键的讨论没什么用处，因为如果你首先谈论GUID标识符，那么GUID很可能是数据模型固有的，必须存储在无论如何，数据模型显然只有一个GUID主键是最简单和最快的选项（到目前为止）。
简而言之 - 如果您需要使用guid识别记录，那么他们的密钥应该是guid！