小编Sol*_*tix的帖子

我一直在与我办公室的各种开发人员就索引的成本以及唯一性是否有益或成本高昂（可能两者兼而有之）进行持续辩论。问题的关键是我们的竞争资源。

背景

我之前读过一个讨论，该讨论指出Unique索引不需要额外的维护成本，因为Insert操作会隐式检查它适合 B 树的位置，并且如果在非唯一索引中发现重复项，则将唯一符附加到键的末尾，否则直接插入。在这一系列事件中，Unique索引没有额外成本。

我的同事反对这种说法，他说这Unique是在寻找 B 树中的新位置之后作为第二个操作强制执行的，因此比非唯一索引维护成本更高。

最坏的情况是，我见过带有标识列（固有唯一）的表，它是表的集群键，但明确声明为非唯一。最糟糕的另一方面是我对唯一性的痴迷，所有索引都被创建为唯一的，当无法定义与索引的显式唯一关系时，我将表的 PK 附加到索引的末尾以确保唯一性得到保证。

我经常参与开发团队的代码审查，我需要能够为他们提供通用的指导方针。是的，应该评估每个索引，但是当您有五台服务器，每个服务器有数千个表，而一个表上的索引多达 20 个时，您需要能够应用一些简单的规则来确保一定的质量水平。

题

Insert与维护非唯一索引的成本相比，唯一性在后端是否有额外成本？其次，将表的主键附加到索引的末尾以确保唯一性有什么问题？

示例表定义

create table #test_index
    (
    id int not null identity(1, 1),
    dt datetime not null default(current_timestamp),
    val varchar(100) not null,
    is_deleted bit not null default(0),
    primary key nonclustered(id desc),
    unique clustered(dt desc, id desc)
    );

create index
    [nonunique_nonclustered_example]
on #test_index
    (is_deleted)
include
    (val);

create unique index
    [unique_nonclustered_example]
on #test_index
    (is_deleted, dt desc, id desc)
include …