综合技术

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

微信扫一扫,分享到朋友圈

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

我在一些表上有许多索引,它们都很相似,我想知道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次,所以任何帮助都会受到赞赏.

弗雷德里克很好地总结了这一点,而这正是金伯利·特里普所宣扬的:集群密钥应该是稳定的(永不改变),不断增加(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! :-)她可以比我更好地解释那些东西……

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

翻译自:https://stackoverflow.com/questions/812891/sql-server-index-which-should-be-clustered

阅读原文...


代码日志

自然语言处理的 ImageNet 时刻已经到来!

上一篇

Spotify后第二家直接上市的企业来了——办公软件Slack

下一篇

您也可能喜欢

评论已经被关闭。

插入图片
SQL Server索引哪些应该是群集的?

长按储存图像,分享给朋友