SQL Server索引哪些应该是群集的？

Question

我在一些表上有许多索引,它们都很相似,我想知道Clustered Index是否在正确的列上.以下是两个最活跃的索引的统计数据:

Nonclustered
I3_Identity (bigint)
rows: 193,781
pages: 3821
MB: 29.85
user seeks: 463,355
user_scans: 784
user_lookups: 0
updates: 256,516

Clustered Primary Key
I3_RowId (varchar(80))
rows: 193,781
pages: 24,289
MB: 189.76
user_seeks: 2,473,413
user_scans: 958
user_lookups: 463,693
updates: 2,669,261

正如你所看到的,PK经常被寻找,但是i3_identity专栏的所有搜索都在对这个PK进行关键查找,所以我真的从I3_Identity的索引中获益很多吗？我应该更改为使用I3_Identity作为群集吗？这可能会产生巨大的影响,因为这个表结构在我工作的地方重复了大约10000次,所以任何帮助都会受到赞赏.

Answer 1

弗雷德里克很好地总结了这一点,这正是金伯利·特里普所宣扬的:聚类键应该是稳定的(永不改变),不断增加(IDENTITY INT),小而独特.

在您的场景中,我宁愿将聚类键放在BIGINT列而不是VARCHAR(80)列上.

首先,使用BIGINT列,可以相当容易地强制执行唯一性(如果您自己不强制执行并保证唯一性,SQL Server将为您的每一行添加一个4字节的"uniquefier")并且它很多平均小于VARCHAR(80).

为什么尺寸如此重要？集群密钥也将被添加到EACH和每个非聚集索引中 - 所以如果你有很多行和很多非聚集索引,那么40-80字节对8字节可以快速成为巨大的区别.

另外,另一个性能提示:为了避免所谓的书签查找(从非聚集索引中的值通过聚类键到实际数据叶页),SQL Server 2005引入了"包含列"的概念在您的非聚集索引中.这些都非常有用,而且经常被忽视.如果您的查询通常需要索引字段加上数据库中的一个或两个其他字段,请考虑包含这些字段以实现所谓的"覆盖索引".再次 - 请参阅Kimberly Tripp的精彩文章 - 她是SQL Server Indexing Goddess!:-)她可以比我更好地解释那些东西......

总而言之:将您的聚类键放在一个小而稳定的独特列上 - 你会做得很好!

渣

Answer 2

快死了:

将聚集索引放在:

• 一个值(几乎)永远不会改变的列

• 新记录上的值按顺序增加/减少的列

• 您执行范围搜索的列