你有几个问题。我将打破其中的一些:
创建索引时,为什么我应该关心集群与非集群?
有时您确实关心行的组织方式。这取决于您的数据以及您将如何使用它。例如,如果您的主键是 a uniqueidentifier
,您可能不希望它是CLUSTERED
,因为 GUID 值本质上是随机的。这将导致 SQL 在整个表中随机插入行,从而导致页面拆分,从而损害性能。如果您的主键值将始终按顺序递增(int IDENTITY
例如),那么您可能希望它是CLUSTERED
,因此您的表将始终在最后增长。
主键是CLUSTERED
默认的,大多数时候你不必担心它。
有人告诉我,非聚集索引的插入和删除速度很慢,因为树需要“重建”。我认为聚集索引不会影响性能吗?
实际上,情况可能正好相反。 NONCLUSTERED
索引作为单独的数据结构保存,但该结构旨在允许进行一些修改而无需“重新构建”。最初创建索引时,您可以指定FILLFACTOR
,它指定在索引的每一页上留下多少可用空间。这允许索引在需要进行页面拆分之前容忍一些修改。即使必须发生页面拆分,它也只会影响相邻页面,而不是整个索引。
同样的行为也适用于CLUSTERED
索引,但由于CLUSTERED
索引存储实际的表数据,因此对索引的页面拆分操作可能会更加昂贵,因为可能需要移动整行(而不是仅键列和索引ROWID
中的)。NONCLUSTERED
以下 MSDN 页面讨论FILLFACTOR
和页面拆分:
http: //msdn.microsoft.com/en-us/library/aa933139 (SQL.80).aspx
主键与聚集唯一索引有什么特别之处?
约束与索引有何不同?
对于这两种情况,我认为更多的是表明你的意图。当您调用某项 a 时PRIMARY KEY
,您声明它是识别给定行的主要方法。PRIMARY KEY
物理上与 a 不同吗CLUSTERED UNIQUE INDEX
?我不知道。行为本质上是相同的,但是使用您的数据库的人可能不清楚您的意图。
Regarding constraints, there are many types of constraints. For a UNIQUE CONSTRAINT
, there isn't really a difference between that and a UNIQUE INDEX
, other than declaring your intention. There are other types of constraints that do not map directly to a type of index, such as CHECK
constraints, DEFAULT
constraints, and FOREIGN KEY
constraints.