繁体 English 中英

SQL Server 2005中没有聚簇索引的原因

[英]Reasons not to have a clustered index in SQL Server 2005

原文 2010-10-27 14:00:48 2 5 sql-server/ sql-server-2005/ tsql/ indexing/ clustered-index

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

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

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

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

5 个解决方案

在任何“正常”数据或查找表上：不，我没有看到任何理由。

在诸如批量导入表或临时表之类的东西上 - 这取决于。

令人惊讶的是，看起来拥有良好的聚簇索引实际上可以加快INSERT或UPDATE等操作。 请参阅Kimberly Tripps优秀的Clustered Index辩论继续....博客文章中她非常详细地解释了为什么会这样。

有鉴于此：我认为没有任何正当理由不在任何SQL Server表上拥有良好的聚簇索引（窄，稳定，唯一，不断增加= INT IDENTITY作为最明显的选择）。

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

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

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

来自“索引女王”的优秀作品！ :-)

集群表与堆表

（关于主题的好文章，请访问www.mssqltips.com ）

HEAP表（没有聚簇索引）

数据不以任何特定顺序存储
除非还有非聚集索引，否则无法快速检索特定数据
数据页未链接，因此顺序访问需要返回索引分配映射（IAM）页面
由于没有聚簇索引，因此不需要额外的时间来维护索引
由于没有聚簇索引，因此不需要额外的空间来存储聚簇索引树
这些表在sys.indexes目录视图中的index_id值为0

集群表

数据基于聚簇索引键按顺序存储
如果查询使用索引列，则可以基于聚簇索引键快速检索数据
链接数据页以加快顺序访问需要额外的时间来维护基于INSERTS，UPDATES和DELETES的聚簇索引
存储聚簇索引树需要额外的空间这些表在sys.indexes目录视图中的index_id值为1

请阅读我的答案“ 无法直接访问集群表中的数据行 - 为什么？” ，首先。 具体项目[2]警告。

创建“数据库”的人是cretins。 他们有：

一堆非规范化的spreadhseets，而不是规范化的关系表
的PKS 都是 IDENTITY列（电子表格链接到彼此;它们必须被导航一个接一个接一个）; 数据库中没有关系访问或关系功能
他们有PRIMARY KEY，它产生了独特的聚集
他们发现这阻止了并发性
他们删除了CI并使他们成为所有NCI
他们懒得完成逆转; 为每个表提名一个备用（当前NCI）成为新的CI
IDENTITY列仍然是主键（它不是真的，但它在这个hamfisted实现中）

对于伪装成数据库的电子表格集合，完全避免CI会变得越来越普遍，并且只有NCI和堆。 显然他们没有得到CI的权力或好处，但是他们没有得到关系数据库的权力或好处，所以谁关心他们没有得到CI的力量（这是为关系数据库设计的，他们的不是）。 他们看待它的方式，无论如何都要经常“重构”这些糟糕的事情，所以为什么要费心呢。 关系数据库不需要“重构”。

如果您需要进一步讨论此响应，请发布CREATE TABLE / INDEX DDL; 否则这是浪费时间的学术论点。

对于目前仍在使用的一些b树服务器/编程语言，固定或可变长度的平坦ascii文件用于存储数据。 将新数据记录/行添加到文件（表）时，记录将（1）附加到文件末尾（或替换已删除的记录）和（2）索引是平衡的。 以这种方式存储数据时，您不必担心系统性能（就b-tree服务器执行的操作而言，返回指向第一个数据记录的指针）。 响应时间仅受索引文件中的节点数的影响。

当您开始使用SQL时，您希望每当编写SQL语句时都必须考虑系统性能。 在非索引列上使用“ORDER BY”语句可以使系统瘫痪。 使用聚簇索引可能会给CPU带来不必要的负载。 这是21世纪，我希望在SQL编程时不必考虑系统性能，但我们仍然这样做。

对于一些较旧的编程语言，每当检索到排序数据时都必须使用索引。 我只希望今天这个要求仍然存在。 我只能想知道有多少公司更新了他们的慢速计算机系统，因为在非索引数据上写的SQL语句写得不好。

在我25年的编程中，我从未需要以特定顺序存储我的物理数据，因此这可能是一些程序员避免使用聚簇索引的原因。 很难知道权衡是什么（存储时间，检索时间），特别是如果您正在设计的系统有一天可能存储数百万条记录。

这是另一个（已经在其他答案中提供过吗？）可能的原因（仍有待理解）：