在我的SQL Server表上使用的最有效的索引和约束是什么？

Question

我们有两个表， ActivityForm和Field ，它们通过ActivityFormField表具有多对多关系。 该ActivityFormFieldValidator表将与一个多到一的关系ActivityFormField表，所以我们给ActivityFormField表标识列（“ActivityFormFieldId”）。 ActivityFormField表还包含诸如在给定活动表单上应显示给定字段的顺序之类的信息。

预期用法如下：

• 最终将有很多活动表单和字段，但是每个活动表单将只附加几个字段（平均可能是十二个）。
• 此表上最常见的查询将是使用给定的ActivityFormId检索ActivityFormField表中的所有条目，并将该数据与Field和ActivityFormFieldValidator表连接起来。
• 新的ActivityFormField条目将每隔一段时间创建一次，但不如上述查询那么频繁。

我的最初反应是使用以下键和索引配置ActivityFormField表：

• 标识列上的主键，上面带有聚簇索引。
• 唯一的非聚集索引，其中包含FieldId和ActivityFormId列。

除了感到我最“正确”或“正常”外，这还满足以下基本要求：

• 确保ActivityForm和Field任何组合只有一个ActivityFormField条目，
• 提供给ActivityFormFieldValidator条目附加的索引关键字，以及
• 在ActivityFormId上提供索引键（用于前面提到的查询）

在插入新的ActivityFormField条目不应导致实际数据重新排序的意义上，它对其聚集索引也“无害”。

但是，考虑到我们计划使用该表的方式，我想知道是否存在键和索引以及集群的另一种组合可能更有效？

更新资料

经过一些额外的研究和思考，我倾向于使表声明看起来像这样：

CREATE TABLE [ActivityFormField](
    [ActivityFormFieldId] [int] IDENTITY(1,1) NOT NULL,
    [ActivityFormId] [int] NOT NULL,
    [FieldId] [int] NOT NULL,
    [SortOrder] [tinyint] NOT NULL,
    CONSTRAINT [PK_ActivityFormField] PRIMARY KEY NONCLUSTERED 
    (
        [ActivityFormFieldId] ASC
    ),
    CONSTRAINT [UK_ActivityFormField_ActivityForm_Field] UNIQUE NONCLUSTERED
    (
        [ActivityFormId] ASC,
        [FieldId] ASC
    )
)

ALTER TABLE [ActivityFormField] WITH CHECK ADD CONSTRAINT [FK_ActivityFormField_ActivityForm] FOREIGN KEY([ActivityFormId])
REFERENCES [ActivityForm] ([ActivityFormId])

ALTER TABLE [ActivityFormField] WITH CHECK ADD CONSTRAINT [FK_ActivityFormField_Field] FOREIGN KEY([FieldId])
REFERENCES [Field] ([FieldId])

CREATE UNIQUE CLUSTERED INDEX IX_ActivityFormField_ActivityForm_SortOrder ON [ActivityFormField] 
(
    [ActivityFormId] ASC,
    [SortOrder] ASC
)

CREATE NONCLUSTERED INDEX IX_ActivityFormField_ActivityForm ON [ActivityFormField] 
    (
        [ActivityFormId]
    )

CREATE NONCLUSTERED INDEX IX_ActivityFormField_Field ON [ActivityFormField] 
    (
        [FieldId]
    )

这种方法使用的身份领域的非聚集索引，对于标准和顺序，其中最常用的查询将检索数据和约束的聚集索引，以确保只有一个ActivityFormField项存在的任意组合ActivityForm和Field 。 唯一约束和索引显然在内部以相同的方式处理，因此我选择了一个约束以表明其主要目的是保持事物唯一。 遵循HLGEM提出的逻辑，其他索引“以防万一”。

Answer 1

与另一个表分开的每个字段的每个字段应单独位于索引中。 与PK不同，这些索引不是自动创建的，几乎总是需要它们。

如果您拥有除PK之外的唯一组合（并且您应该在大多数表中使用代理Pk），则一定要在字段组合上放置唯一索引，否则将造成数据完整性问题。 可能需要其他索引，具体取决于您将在查询表中使用的where子句。 索引的需求可能会随着表大小的增加而变化，因此无需感到您必须在第一时间就获得所有正确的索引。

Answer 2

不幸的是，没有一个简单的答案。 我将从您自己提出的建议开始，然后再用适当数量的数据加载表，并通过探查器将其踢出，并查看生成的执行计划。 基准测试确实是解决问题的唯一方法。

如果您获得索引搜索，那么一切就很好了：不再需要真正的工作。 如果您有索引扫描，请查看是否可以调整索引以将其转换为搜索。 如果在执行计划中看到任何书签查找，请考虑将其他列添加到索引中，以便索引本身覆盖查询。