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非常不同)。我的访问方式有两种：

• By OBJECTID:每次对象更改时，键列表都会更改，因此需要基于OBJECTID的键。变化经常发生。
• 通过ITEMKEY:这是用于关键字搜索，也经常发生。

因此，我可能需要两个键，并选择一个用于聚集索引(访问频率更高的键，或者我希望速度达到的位置，现在让我们假设我将对聚集对象进行优先排序)。我所困惑的是我应该如何设计它。

我的问题是，哪个更好：

a) (OBJECTID，ITEMTYPE，ITEMKEY)的聚集指数，然后是(ITEMKEY)的聚集指数。我担心的是，由于聚集索引非常大(2个ints，1个字符串)，索引就会很大，因为所有索引项都必须指向聚集键。

b)创建一个新列，将运行的标识DIRECTORYID (整数)作为主键和聚集索引，并为(OBJECTID、ITEMTYPE、ITEMKEY)和key (ITEMKEY)声明两个索引。这将使索引空间最小化，但查找成本更高。

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

( d) Err...maybe有一个更好的方法来满足需求？

谢谢你，安德鲁

Answer 1

如果可能的话，尽量保持您的聚集键尽可能小，因为它也将添加到表中的所有非聚集索引中。

因此，如果可能的话，我将使用INT，或者可能使用两个INT的组合--但肯定不会使用VARCHAR列--特别是如果该列可能很宽(> 10个字符)并且必然会更改。

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

添加代理项DirectoryID将满足集群密钥的所有关键条件：

• 小的
• 稳定
• 独一无二
• 不断增加

你的其他非聚类指数将受到最小的影响。

参见金伯利特里普关于在Server表中选择一个好的集群密钥的主要标准的优秀博客帖子 --非常有用和具有启发性！

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