SQL Server 2008中的索引与唯一键

时间:2010-11-13 14:25:30

标签: sql-server indexing

我有下表用于连接3个表:

ClientID int
BlogID  int
MentionID   int

假设查询总是来自ClientID,我可以创建1个多列索引(ClientID,BlogID,MentionID)。

问题是,我应该将其创建为聚簇索引还是唯一键?我理解聚簇索引将数据存储在其叶节点上。当然,在这种情况下,索引数据,所以我不知道SQL Server是否会复制数据。尽管如此,我在MSDN上找不到关于使用“唯一密钥”的重要性的任何内容。

这与Type = Index& IsUnique =是吗?

有人可以告诉我各方面的优势吗?

5 个答案:

答案 0 :(得分:4)

聚簇索引是“表本身”,即索引节点排列在树中,其叶节点包含行数据。聚集索引不必声明为唯一(尽管通常是);如果它不是唯一的,则服务器隐式地向该索引添加“uniqalizer”,以便唯一地标识每一行。

其他索引将聚集索引值存储为其叶节点(如果它们包含在CREATE INDEX staetment中的INCLUDE子句中,则可能存储其他一些列。)

任何索引都可能被声称为唯一,因此服务器会执行额外检查以防止重复值进入表格。

答案 1 :(得分:1)

  • 一个unique index,一个unique key和 一个unique constraint基本上是 同一件事情。他们导致了 强制唯一性的索引。

  • 群集意味着索引 成为桌子本身。很好 拥有聚集索引,否则 桌子挂在一个 无序堆。

Unique和clustered是不相关的属性。您可以以任何您喜欢的方式组合它们。所以在你的情况下,我会创建一个独特的聚簇索引。通常的方法是将索引创建为clustered primary key

答案 2 :(得分:1)

如果您在三列上创建群集唯一索引,则数据将重复。

独特的聚集索引 数据 - 和索引同时:-)

由于这是一个三向连接表,因此这个聚簇索引可能确实很有意义。我会说:去吧!

答案 3 :(得分:1)

UNIQUE INDEXUNIQUE CONSTRAINT有些不同的概念。

  • UNIQUE CONSTRAINT是一个逻辑概念,意思是“确保此列是唯一的,无论如何”
  • UNIQUE INDEX是一个物理概念,意味着“在此列上创建B-Tree索引,并且每当插入重复项时都会失败”

后者暗示前者,但反之亦然。

例如,在Oracle中,如果col1上有非唯一索引:

  • CREATE UNIQUE INDEX (col1)将失败并说“这些列已经编入索引”
  • ALTER TABLE ADD CONSTRAINT UNIQUE(col1)将成功并使用现有索引来监管约束。

如果您只想让列唯一,请使用CONSTRAINT;如果您知道INDEX索引是您想要的({以加快搜索等),请使用B-Tree

答案 4 :(得分:1)

您似乎要求区别:

 MYTABLE
 id integer primary key autoincrement
 clientid integer
 blogid integer
 mentionid integer
 -- with a unique composite index on (clientid, blogid, mentionid) and three foreign key constraints

 MYTABLE
 clientid 
 blogid
 mentionid
 -- with a composite primary key on (clientid, blogid, mentionid) and three foreign key constraints

 MYTABLE
 id integer primary key autoincrement
  clientid integer
  blogid integer
  mentionid integer
  with an index on clientid and also an index on blogid and the three foreign key constraints

在第一个中,您拥有整数主键的索引以及三元组上的备用唯一索引。如果是第二个,则三元主键上只有唯一索引。在第三个中,你有一个关于整数主键和另外两个非唯一索引的唯一索引,一个在clientid上,另一个在blogid上。

第二个选项的效率略微提高效率将是 de minimis ,因此我将决定基于其他因素。第三是查询方面最灵活,编码更简单;它提供了客户端和博客上的索引的好处,以防您想在WHERE子句中使用博客而不是客户端进行查询。至于编码,一些GUI工具和中间件在使用多部分主键时遇到问题,并且当必须处理单个整数PK列时,更新/插入/删除逻辑将更简单。我发现代码简单性和易维护性比查询响应时间的几秒或几分之一秒的改进要好得多。