SQL Server 2005中没有聚簇索引的原因 [英] Reasons not to have a clustered index in SQL Server 2005

问题描述

我为SQL SERVER 2005数据库继承了一些数据库创建脚本。

I've inherited some database creation scripts for a SQL SERVER 2005 database.

我注意到的一件事是所有主键都创建为 NON CLUSTERED 索引而不是群集。

One thing I've noticed is that all primary keys are created as NON CLUSTERED indexes as opposed to clustered.

我知道每个表只能有一个聚簇索引并且你可能想要将它放在非主键列上以便查询搜索性能等。但问题中的表中没有其他 CLUSTERED 索引。

I know that you can only have one clustered index per table and that you may want to have it on a non primary key column for query performance of searches etc. However there are no other CLUSTERED indexes on the tables in questions.

所以我的问题是，除了上述内容之外，还有任何技术原因没有主键列上的聚簇索引。

推荐答案

在任何普通数据或查询表上：不，我没有看到任何理由。

On any "normal" data or lookup table: no, I don't see any reason whatsoever.

开像批量导入表或临时表这样的东西 - 这取决于。

On stuff like bulk import tables, or temporary tables - it depends.

对某些人来说，令人惊讶的是，看起来实际上有一个好的聚簇索引加速 INSERT或UPDATE等操作。请参阅Kimberly Tripps优秀聚集指数辩论继续.... 博客文章中她非常详细地解释了为什么会这样。

To some people surprisingly, it appears that having a good clustered index actually can speed up operations like INSERT or UPDATE. See Kimberly Tripps excellent The Clustered Index Debate continues.... blog post in which she explains in great detail why this is the case.

从这个角度来看：我没有看到任何有效理由不具有良好的聚集索引（窄，稳定，唯一，不断增加= INT IDENTITY 作为最明显的选择）任何SQL Server表。

In this light: I don't see any valid reason not to have a good clustered index (narrow, stable, unique, ever-increasing = INT IDENTITY as the most obvious choice) on any SQL Server table.

要深入了解如何以及为何选择集群密钥，请阅读Kimberly Tripp关于该主题的所有优秀博文：

To get some deep insights into how and why to choose clustering keys, read all of Kimberly Tripp's excellent blog posts on the topic:

http：// www。 sqlskills.com/BLOGS/KIMBERLY/category/Clustering-Key.aspx

http://www.sqlskills.com/BLOGS/KIM BERLY / category / Clustered-Index.aspx

索引女王的精彩内容！ :-)

Excellent stuff from the "Queen of Indexing" ! :-)

这篇关于SQL Server 2005中没有聚簇索引的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！