SQL Server GUID（来自 Active Directory）与 Int

Question

我们从旧的订购系统中迁移了大量数据。该系统将用户创建的每个订单的姓名缩写存储在我们的“订单”表中。现在我们有了一个查看活动目录的视图，我想使用活动目录 objectguid（或引用该 guid 的内容）更新这些缩写。这将使我们能够更改活动目录中的用户姓名缩写，而不必担心更新“Orders”表记录。

我读到，使用 guid 与 int 时索引性能很差。可能解决此问题的一种方法是使用一个将 guid 映射到 int 的表，然后将 int 值存储在我们的订单表中。这是个好主意吗？有什么想法吗？

Answer 1

我假设的 USER 的实体已经在你的数据库设计存在但是，如果没有的话，我相信你的解决方案将需要它。

所以假设的 USER 的实体存在，正如你所描述的那样，你可以放置在订单的用户名（INT）的表，从而与所有相关的 USER 的细节到的订单的，而不仅仅是缩写（注：首字母应该说是不被存储在订单的表，而是在 USER 或 USER_DETAILS 表，尽管本讨论的不聚焦）。

您可以再GUID列添加到用户表。我不认为一个单独的查找表是必要的。

请感？

Answer 2

GUID 上的索引性能通常与 16 字节字段上的其他索引没有什么不同。GUID 对于性能来说是致命的，当您将它们用作 聚类键 在 SQL Server 表上。

SQL Server 表 是 聚簇键，并按该键进行物理排序。由于 GUID 本质上是完全随机的，这会很快导致大量索引碎片，因此需要 a) 不断的馈送、维护和重组，但 b) 即使您每晚都进行重组，仍然会受到影响。因此，实际上，最佳实践是避免使用 GUID（甚至是新的“顺序”GUID）作为集群键。

有关为什么 GUID 的聚集键性能非常差的更多背景信息和一些优秀文章，请参阅“索引女王”Kimberly Tripp 的博客：

• GUID 作为主键
• 聚集索引争论仍在继续......
• 聚集索引争论......再次！

她的见解是最有价值的——阅读它、内化它、遵循它！你不会后悔的。

马克