1. 首页
  2. 问答
  3. 在SQL Server 2005中没有聚集索引的原因

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

2010-10-27 88 views
8

我已经继承了SQL SERVER 2005数据库的一些数据库创建脚本。在SQL Server 2005中没有聚集索引的原因

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

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

所以我的问题是有没有任何技术原因除了上面的主键列上聚集索引。

来源

2010-10-27 AJM

+1

“我注意到的一件事是，所有的主键都创建为非集群索引，而不是clustured”为什么我观察到相反？ – 2010-10-28 02:19:51

+0

@ vgv8 - 澄清，它是我继承的数据库脚本明确地将密钥设置为非群集。 – AJM 2010-10-28 08:40:43

+1

我也仍然无法理解它http://stackoverflow.com/questions/3970430/why-when-how-is-whole-clustered-index-scan-chosen-rather-than-full-table-scan，虽然我不明白为什么/何时有聚集索引 – 2010-10-28 10:35:46

回答

8

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

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

对一些人来说令人惊讶的是，似乎有一个好的聚集索引实际上可以加速像INSERT或UPDATE这样的操作。请参阅Kimberly Tripps出色的The Clustered Index Debate continues....博客文章，其中她详细解释了为什么会出现这种情况。

有鉴于此：我没有看到任何有效原因不有一个良好的聚集索引（窄的，稳定的，独特的，不断增加= INT IDENTITY是最明显的选择）上的任何SQL Server表。

为了得到一些深刻的见解如何以及为什么要选择集群键，读取所有金佰利特里普的优秀博客文章的题目是从“皇后

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

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

优秀的东西索引“！:-)

来源

2010-10-27 14:03:32

6

Clustered Tables vs Heap Tables

堆表（没有聚集索引）

  • 数据不被存储在任何特定的顺序

    （在上主体www.mssqltips.com好文章）

  • 具体数据c一个不被检索 很快，除非也有 非聚集索引

  • 数据页没有联系，所以 顺序访问需要重提 的索引分配映射（IAM）

  • 页

    由于没有聚簇索引， 额外的时间，不需要到 维护索引

  • 由于没有聚簇索引， 有不TH E需求额外 空间来存储聚集索引 树

  • 这些表具有 0在sys.indexes目录视图

簇表一个index_id的值

  • 数据的存储顺序依据 聚簇索引键

    • 个

  • 数据可以快速检索基于 聚集索引键，如果 查询使用索引列

  • 数据页链接更快 顺序访问，以保持聚集索引基于 其他需要时间 插入，更新和删除操作

  • 是需要额外的空间来存储 簇索引树 这些表在sys.indexes目录具有1的值index_id的查看

来源

2010-10-27 14:10:41 Branimir

1

请在“”下阅读我的回答没有直接访问聚集表中的数据行 - 为什么？首先是。具体项目[2]警告。

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

  • unnormalised spreadhseets，没有规范化的关系表的一堆
  • 的的PK 所有 IDENTITY列（电子表格链接到对方;他们要一个导航逐单由酮）;有跨数据库没有关系访问或关系功率
  • 他们有PRIMARY KEY，从而产生独特的群集
  • 他们发现，防止并发
  • 他们删除的CI，使它们都NCIS
  • 他们太懒惰完成逆转;提名备用（电流NCI）成为新的CI，每个表
  • IDENTITY列仍是主键（这是不是真的，但它在这个hamfisted实现）

对于这种伪装成数据库的电子表格集合，完全避免配置项变得越来越普遍，并且只有NCI和堆。很明显，他们没有获得CI的权力或好处，但是他们没有得到关系数据库的力量或好处，所以谁在乎他们没有获得CI的权力（这是为关系数据库设计的，他们的不是）。他们看待它的方式，他们不得不每隔一段时间“重构”事物，所以为什么要麻烦。关系数据库不需要“重构”。

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

来源

2010-10-29 13:39:56 PerformanceDBA

+0

10您能否提供任何有关“完全避免CI越来越常见”以及“CI的权力或好处”的参考？ – 2010-11-03 04:01:46

+1

@ vgv8：*如果您需要进一步讨论此响应，请发布CREATE TABLE/INDEX DDL;否则这是一个浪费时间的学术论证*你从过去的经验中得知：MS很少有深入的信息，这就是为什么专家有自己的方法，为什么人们付钱给他们。试试Google。尝试StackOverflow。我发现这[这个职位]（http://stackoverflow.com/questions/3336934/）这恰好部分地回答你的问题。有一天，我会写一本书，然后你会有充分的参考。 – PerformanceDBA 2010-11-03 04:42:56

0

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

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

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

在我25年的编程中，我从来不需要以特定顺序存储我的物理数据，所以也许这就是为什么有些程序员避免使用聚簇索引。很难知道什么是折衷（存储时间，取决于检索时间），特别是如果您正在设计的系统可能有一天存储数百万条记录。

来源

2016-06-09 00:11:37 mjb

相关问题

 相关问题