SQL Server - 字典的聚集索引设计

Question

希望从中得到一些建议。我有一个表，我想在其中跟踪一个对象以及与该对象相关的键列表。示例：

OBJECTID   ITEMTYPE   ITEMKEY
--------   --------   -------
1          1          THE
1          1          BROWN
1          2          APPLE
1          3          ORANGE
2          2          WINDOW

OBJECTID 和ITEMKEY 都具有很高的选择性（即OBJECTID 和ITEMKEY 变化很大）。我的访问有两种方式：

• 通过 OBJECTID：每次对象更改时，键列表都会更改，因此需要基于 OBJECTID 的键。变化经常发生。

• 按ITEMKEY：用于关键字搜索，也经常发生。

所以我可能需要两个键，并选择一个作为聚集索引（访问更频繁的那个，或者我想要的速度，现在让我们假设我将优先考虑聚集的 OBJECTID）。我很困惑的是我应该如何设计它。

我的问题是，哪个更好：

a）（OBJECTID，ITEMTYPE，ITEMKEY）的聚集索引，然后是（ITEMKEY）的索引。我担心的是，由于聚集索引太大（2 个整数，1 个字符串），索引也会很大，因为所有索引项都必须指向聚集键。

b) 创建一个新列，以运行标识 DIRECTORYID（整数）作为主键和聚集索引，并声明两个索引为 (OBJECTID,ITEMTYPE,ITEMKEY) 和 (ITEMKEY)。这将最大限度地减少索引空间，但查找成本更高。

c) (OBJECTID,ITEMTYPE,ITEMKEY) 的聚集索引及其上的 (ITEMKEY,ITEMTYPE,OBJECTID) 的物化视图。我的逻辑是，这避免了键查找，并且仍然与 a) 中查找的索引一样大，但代价是更高的开销。

d) 呃...考虑到要求，也许有更好的方法？

提前致谢， 安德鲁

Answer 1

如果可能，请尝试使聚集键尽可能小，因为它也会添加到表上的所有非聚集索引中。

因此，如果可能的话，我会使用 INT，或者可能使用两个 INT 的组合 - 但绝对不会使用 VARCHAR 列 - 特别是如果该列可能很宽（> 10 个字符）并且绑定到改变。

所以在你提出的选项中，我个人会选择 b) - 为什么？

添加代理 DirectoryID 将满足集群键的所有关键标准：

• 小、
• 稳定、
• 唯一、
• 不断增加

，并且您的其他非集群索引将受到最小的影响。

请参阅 Kimberly Tripp 的杰出的博客文章介绍了在 SQL Server 表上选择良好集群键的主要标准 - 非常有用且具有启发性！

为了满足您的查询要求，我将添加两个非聚集索引，一个位于 ObjectID 上（可能包括其他经常需要的列），另一个位于 ItemKey 上以按键名搜索。