SQL Server什么样的索引群？

胡泽标

我在某些表上有许多索引，它们都相似，并且我想知道聚集索引是否在正确的列上。以下是两个最活跃索引的统计信息：
+ V3 g1 O, G: [9 D; wNonclusteredI3_Identity (bigint)rows: 193,781pages: 3821MB: 29.85user seeks: 463,355user_scans: 784user_lookups: 0updates: 256,516Clustered Primary KeyI3_RowId (varchar(80))rows: 193,781pages: 24,289MB: 189.76user_seeks: 2,473,413user_scans: 958user_lookups: 463,693updates: 2,669,261如你所见，经常搜索PK，但是对i3_identity所有列的搜索都在这里PK所以，我真的是从吗？I3_Identity索引受益匪浅？我应该改用它I3_Identity作为一个群体吗？因为这个表结构在我工作的地方重复了1万次左右，可能会产生很大的影响，所以我们会非常感激。
                                                               
    解决方案:                                                               
                                                                弗雷德里克（Frederik）这是金伯利的好总结·特里普（Kimberly
Tripp）所鼓吹的：集群密钥应该稳定（永不改变），不断增加（IDENTITY INT），小而独特。
* I& o/ S6 U# \8 i) x在你的计划中，我宁愿把集群键放在你的计划中BIGINT列出，而不是VARCHAR（80）列上。
首先，通过BIGINT列，可以很容易地实现唯一性(如果你不强制执行并确保唯一性，SQL
Server将4字节的独特性添加到你的每一行中是非常必要的平均比率VARCHAR（80）小。
为什么尺寸这么重要？还将添加集群密钥EACH以及每个非集群索引-
) X+ j. w! i3 j9 V  k8 b. ]所以，如果你有很多行和非集群索引，那么40-80字节和8字节的字节数可以快速增加差异。
此外，另一个性能提示：为了避免所谓的书签搜索（通过集群键从非集群索引中的值进入实际数据叶页），SQL Server
( M/ I, }+ i& H2 [+ B, i2005年引入了包含列的概念。在你的非聚集索引中。这些都很有帮助，而且经常被忽视。如果您的查询通常需要索引字段和数据库中只有一其他字段，请考虑包括这些字段来实现所谓的覆盖索引。-
1 O% L3 Y/ p. C1 f# Z请参见Kimberly Tripp的精彩文章-她是SQL Server索引女神！:-)，她能比我更好地解释这些事情。
) W$ w$ j/ X7 ^4 D综上所述，把你的集群键放在一个小的、稳定的、唯一的列上-你会做得很好！
马克