我正在开发一个维护大约 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 生成的。
查看这个简化的基准脚本，演示我的意思。
使用您的测试用例，这是预期的。第一个测试只增长一个包含一个字段的表。另外两个构建两个列和两个索引。
这里有一个更合适的测试。所有三个测试都有一个 GUID 字段和一个 INT（或 BIGINT）字段。所有字段都被索引。在我的服务器上，在 UID 上具有非聚集索引的 INT 上具有 PK 的测试表要快 2 秒。
这是我的测试代码： http: //pastebin.com/MFTA3Da1
After much testing, it turns out that using guid pk is faster than int surrogate key and a guid natural key.
The talk about avoiding GUID primary keys due to clustering and fragmentation is of little utility since if you're talking about GUID identifiers in the first place, then it's likely that the GUID is intrinsic to the data model and must be stored in the data model anyway, so clearly a single GUID primary key is the simplest and fastest option (by far).
In a nutshell - if you need to identify records with guids then their key should be the guid!