我有一个名为Foo的表，该表具有两列A和B。这两个列都是其他两个表的外键。这些列共同构成了主键，默认情况下，它具有该主键的聚集索引。
我的问题是...为B创建另一个非聚集索引是否对我完全有益？还是不必要？
答案 0 :(得分：2)
首先，请提供一些背景知识，以确保我们位于同一页面上。
听起来您也有Bar表，其中以A为键，Baz，表中B为键，其中{{1} }表在Foo和Bar之间保持多对多的交集关系，如下所示：
Baz如果是这样，您需要问自己如何使用这种关系。如果您将更频繁地从Bar(A) <=> Foo(A,B) <=> Baz(B)
开始，然后需要发现相关的Bar值，则主键（聚集键）应为Baz。如果您将更频繁地从(A, B)开始，然后需要获取Baz值，则主键应为Bar。
对于这个问题，我们得到了(B, A)的情况，并询问附加的(A, B)键是否是一个好主意。因此，我们应该假设您会更频繁地从(B, A)记录开始，并且需要了解相关的Bar记录：Baz，或者最糟糕的是50/50。
现在回答问题。
额外的Bar -> Foo -> Baz索引（甚至只是(B) INCLUDES A） 可能会有所帮助，如果您有时还从(B, A)记录开始并且需要了解相关信息当您有双向查询Baz时，Bar条记录（Baz -> Foo -> Bar）...。
但是记住其他索引具有存储，内存和维护成本也很重要。附加索引是否会对您的应用程序产生净积极影响，取决于您是否经常使用这种查找方式来克服这些费用。值得一提的是，如果表经常更改，则成本会更高，因为每次更改都必须同时更新两个索引。
答案 1 :(得分：0)
如果没有数据库工作量的一些详细知识，就不能确定地说。这取决于您的用法。
如果您从B向共享表查询很多内容，则可能在B上有索引将有所帮助。您可以使用多种工具来查看是否应根据工作量优化索引，包括SQL Server附带的数据库引擎优化顾问。
另外，如果您对B外键的引用完整性有所怀疑，那么通常也可以使用索引。
顺便说一句，我假设您的主键是A，然后是B，并且是聚簇索引。因此，聚集索引可以处理A，并且不需要在A上有单独的索引。