我们从旧订购系统迁移了大量数据。该系统将用户的首字母缩写存储在我们的“订单”表中，用于他们创建的每个订单。现在我们有了一个查看活动目录的视图，我想用活动目录objectguid（或引用guid的东西）更新这些首字母缩写。这将允许我们更改活动目录中的用户首字母，而不必担心更新“订单”表记录。SQL Server GUID（来自Active Directory）vs Int
我读过使用guids vs ints时索引性能低下的问题。解决这个问题的方法之一是有一个表格，将guid映射为整数，然后将int值存储在我们的订单表中。这是个好主意吗？有什么想法吗？
我假设一个用户实体已经存在于您的数据库设计中，但是，如果它不存在，那么我相信您的解决方案将需要它。
所以假设USER实体存在，正如你所描述的那样，你可以将用户ID（INT）在订单表，从而一切有关USER细节的ORDER，而不仅仅是缩写（注意：缩写应该说是不被存储在ORDER表而是USER或USER_DETAILS表，尽管该讨论的不是重点）。
然后，您可以将GUID列添加到USER表。我不认为一个单独的查找表是必要的。
有意义吗？
GUID的索引性能与16字节字段上的其他索引通常没有区别。在GUID对性能致命的情况下，当您在SQL Server表上使用它们作为集群密钥时。
SQL Server表是聚集键和物理由该键进行排序。由于GUID本质上是完全随机的，因此这会导致很快的大量索引碎片化，因此需要a）持续的进料和维护和重组，但b）即使每晚都进行重组仍然会受到影响。所以最好的做法是避免GUID（即使是新的“顺序”GUID）。
欲了解更多背景资料和为什么的GUID使很差聚集键一些优秀的评论，看到金佰利特里普的“索引女王”的博客：
她的观点是最宝贵的 - 读它，它内在化，遵循它！你不会后悔的。
Marc
如何使映射表比使用guid作为表中的字段更好，但不是集群密钥？ – 2009-07-03 21:06:32
我的思考过程是映射表将有大约100行，可以快速查找int，并且如果使用索引ints而不是索引uniqueidentifiers的性能优势，那将是值得的，因为我们的orders表有超过400万行。请让我知道，如果我的思维方式是完全脱离基地:) – 2009-07-03 21:12:29