sql-server - SQL Server GUID（来自 Active Directory）与 Int

Question

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

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

Answer 1

我假设您的数据库设计中已经存在USER实体，但如果它不存在，那么我相信您的解决方案将需要它。

因此，假设USER实体存在，正如您所描述的，您可以将 UserID(int) 放在ORDERS表中，从而将所有相关的USER详细信息与ORDER相关联，而不仅仅是首字母（注意：首字母可能不应该存储在ORDER表，而是USER或USER_DETAILS表，尽管不是本次讨论的重点）。

然后，您可以将 GUID 列添加到 USER 表中。我认为不需要单独的查找表。

有道理？

Answer 2

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

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

有关 GUID 为什么会产生非常差的集群键的更多背景信息和一些出色的文章，请参阅“索引女王”Kimberly Tripp 的博客：

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

她的洞察力是最有价值的——阅读它，内化它，跟随它！你不会后悔的。

马克