代码之家  ›  专栏  ›  技术社区  ›  StriplingWarrior

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

  •  0
  • StriplingWarrior  · 技术社区  · 15 年前

    我们有两张桌子, ActivityForm Field 通过 ActivityFormField 桌子这个 ActivityFormFieldValidator 表将与 ActivityFormField ActivityFormField ActivityFormField

    预期用途如下:

    • 最终会有很多活动表单和字段,但每个活动表单上只会附加少量字段(平均可能有十几个)。
    • 此表上最常见的查询是检索表中的所有条目 具有给定参数的表 ActivityFormId ,并将该数据与 领域 ActivityFormFieldValidator 桌子。
    • 新的 条目将每隔一段时间创建一次,但不会像上面提到的查询那样频繁。

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

    • 标识列上的主键,其上有聚集索引。
    • 一个唯一的非聚集索引,包括 FieldId 活动形式 柱。

    除了感觉自己最“正确”或“正常”之外,这还满足以下基本要求:

    • 确保只有一个 ActivityFormField 任何组合的条目 活动形式 领域
    • 为提供索引键 ActivityFormFieldValidator 要附加到的条目,以及
    • 在上提供索引键 活动形式 (对于前面提到的查询)

    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]
        )
    

    此方法在标识字段上使用非聚集索引,最常用的查询检索数据的条件和顺序使用聚集索引,并使用约束确保只有一个 条目存在于以下项的任意组合中: 领域

    2 回复  |  直到 12 年前
        1
  •  0
  •   HLGEM    15 年前

    作为另一个表的单独fk的每个字段都应该单独位于索引中。与PKs不同,这些索引不是自动创建的,几乎总是需要的。

    如果您有PK以外的唯一组合(如果在大多数表中使用代理PK,您应该这样做),则务必在字段组合上放置唯一索引,否则将导致数据完整性问题。根据查询表时使用的where子句,可能需要其他索引。索引需求可能会随着表大小的增长而变化,因此无需感觉必须在第一时间获得所有索引。

        2
  •  0
  •   Callie J    15 年前

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

    若你们得到了索引搜索,那个么一切都是好的:并没有更多的工作真正需要。如果您有索引扫描,那么看看是否可以调整索引以将其转换为搜索。如果在执行计划中看到任何书签查找,请考虑将其他列包含到索引中,以便索引本身覆盖查询。