关系表的最佳索引策略是什么？

Question

关系表是表示多对多（m：n）关系的常用解决方案。

在最简单的形式中，它将引用两个相关表的外键组合到一个新的复合主键中：

A        AtoB     B
----     ----     ----
*id      *Aid     *id
data     *Bid     data

如何在每个JOIN情况下为索引提供最佳性能？

1. 聚集索引（Aid ASC, Bid ASC）（无论如何，这是强制性的，我猜）
2. 选项＃1加上（Bid ASC, Aid ASC）
的附加索引
3. 或选项＃1加上（Bid ASC）
的附加索引
4. 还有其他选择吗？供应商特定的东西，也许？

Answer 1

我做了一些测试，这是更新：

要涵盖所有可能的情况，您需要：

CLUSTERED INDEX (a, b)
INDEX (b)

这将涵盖所有JOIN个问题和ORDER BY

请注意，B上的索引实际上已在(B, A)上排序，因为它引用了群集行。

只要您的a和b表格中有PRIMARY KEY个ID，不就需要创建其他索引来处理{{ 1}}。

有关详细信息，请参阅我博客中的条目：

• Indexing a link table

Answer 2

我猜解决方案2是最佳的。我通过查看值并期望哪一个具有更多不同的行来选择聚簇索引的顺序。那是第一个。在父表上使用unique或primary key索引也很重要。

根据DBMS，数字3可能与数字2一样好。在非聚集索引中考虑除了引用实际行之外的任何其他值的值（聚簇索引的键）可能会或可能不够智能。如果它可以使用它，那么3号会更好。

Answer 3

通过检查SQL Server 2005中的执行计划，我做了一些快速而肮脏的测试。 计划显示SQL在大多数查询的Aid，Bid上使用聚簇索引。在Bid（ASC）上添加索引表明它用于类型

的查询

select * from A
    inner join AtoB on Aid = A.id
    inner join B on Bid = B.id
where Bid = 1

所以我投票赞成解决方案＃3。