在 SQL Server 2005 中没有聚集索引的原因答案

【问题标题】：Reasons not to have a clustered index in SQL Server 2005在 SQL Server 2005 中没有聚集索引的原因
【发布时间】：2011-05-01 08:23:15
【问题描述】：

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

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

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

所以我的问题是，除了上述之外，还有什么技术原因不在主键列上设置聚集索引。

【问题讨论】：

“我注意到的一件事是所有主键都创建为非集群索引而不是集群索引”为什么我观察到相反的情况？
@vgv8 - 澄清一下，我继承的数据库脚本明确将键设置为非集群。
我仍然无法理解 stackoverflow.com/questions/3970430/… ，尽管我完全不明白为什么/何时需要聚集索引

标签： sql-server sql-server-2005 tsql indexing clustered-index

【解决方案1】：

在任何“正常”数据或查找表上：不，我看不出任何原因。

关于批量导入表或临时表之类的东西 - 视情况而定。

令一些人惊讶的是，拥有一个良好的聚集索引实际上可以加快诸如 INSERT 或 UPDATE 之类的操作。请参阅 Kimberly Tripps 出色的 The Clustered Index Debate continues.... 博客文章，其中她详细解释了为什么会这样。

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

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

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

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

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

【讨论】：

【解决方案2】：

Clustered Tables vs Heap Tables

（关于主题的好文章www.mssqltips.com）

HEAP 表（无聚集索引）

数据不存储在任何特定的顺序
无法检索特定数据很快，除非也有非聚集索引
数据页未链接，因此顺序访问需要回溯到索引分配图 (IAM) 页面
由于没有聚集索引，不需要额外的时间维护索引
由于没有聚集索引，不需要额外的存储聚集索引的空间树
这些表的 index_id 值为 sys.indexes 目录视图中的 0

聚簇表

数据按顺序存储聚集索引键
可以快速检索数据在聚集索引键上，如果查询使用索引列
链接数据页以加快速度顺序访问需要额外的时间来维护基于插入、更新和删除
需要额外的空间来存储聚集索引树这些表在 sys.indexes 目录中的 index_id 值为 1 查看

【讨论】：

【解决方案3】：

请先阅读我在“无法直接访问聚集表中的数据行 - 为什么？”下的答案。。特别是第 [2] 项警告。

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

一堆未规范化的电子表格，未规范化的关系表
PK 是所有 IDENTITY 列（电子表格相互链接；它们必须一个接一个地导航）；整个数据库没有关系访问或关系权力
他们有 PRIMARY KEY，产生 UNIQUE CLUSTERED
他们发现这会阻止并发
他们移除了 CI，并将它们全部设为 NCI
他们懒得完成反转；为每个表提名一个替代（当前 NCI）成为新 CI，
IDENTITY 列仍然是主键（它不是真的，但它在这个笨拙的实现中）

对于此类伪装成数据库的电子表格集合，完全避免 CI 并仅使用 NCI 和堆变得越来越普遍。显然他们没有获得 CI 的力量或好处，但是地狱，他们没有获得关系数据库的力量或好处，所以谁在乎他们没有获得 CI 的力量（这是为关系数据库设计的，他们的不是）。他们看待它的方式，无论如何他们必须经常“重构”这该死的东西，所以为什么要麻烦。关系数据库不需要“重构”。

如果您需要进一步讨论此回复，请发布 CREATE TABLE/INDEX DDL；否则就是浪费时间的学术争论。

【讨论】：

您能否就“完全避免 CI 变得越来越普遍”和“CI 的力量或好处”提供任何参考？
@vgv8: 如果您需要进一步讨论此回复，请发布 CREATE TABLE/INDEX DDL；否则这是一个浪费时间的学术争论 你从过去的经验中知道：关于 MS 的深入信息很少，这就是为什么专家有自己的方法，以及为什么人们付给他们大笔钱。试试谷歌。试试 StackOverflow。我发现这个this post 恰好部分回答了你的问题。有一天，我会写一本书，然后你就会有完整的参考。

【解决方案4】：

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

SQL Server - Poor performance of PK delete

我希望，我稍后会更新，但现在更希望链接这些主题

更新：
What do I miss in understanding the clustered index?

【讨论】：

【解决方案5】：

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

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

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

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

【讨论】：