2010-10-29 34 views
0

在没有表行通过IAM((索引分配映射表)。访问的任何指数的
我可以以编程方式使用IAM直接访问行?我在理解聚集索引时错过了什么?

确实没有索引的意思是只有这样,才能具体阅读行全表扫描读取所有的表?
为什么IAM不能从事更具体直接访问?

“如果表是一个堆(换句话说,它没有聚集索引),书签是行标识符(RID),它是File形式的实际行定位符#:Page#:Slot#“[1a]

slot没有进一步的定义。那么其他的消息来源表明Slot#真的是行号。正确?还是需要与IAM进一步并置来确定特定行?

现在,引入聚簇索引意味着不能直接访问数据,只能通过最终聚簇索引查找或按顺序遍历聚簇叶节点。

我是否正确理解聚簇索引的引入仅对选择连续的相邻(范围)行和仅通过聚簇索引键有利?
聚类表有哪些好处?

我是否正确理解聚集索引引入会加剧非聚集索引参与非精确匹配查询的性能优势?没有直接访问,顺序访问不能并行化,非聚集索引通过聚簇索引键等增加,是正确的?

嗯,我看到聚集一张表对于非常具体而且很好理解的上下文是有意义的,而主键的创建总是默认在聚集表中。为什么?

聚簇索引理解中我错过了什么?

[1]
里面微软的SQL Server™2005:存储引擎
通过卡伦·德莱尼 - (质坚实学习)
................. ..............................
出版商:Microsoft Press
Pub日期:2006年10月11日
打印ISBN- 10:0-7356-2105-5
印刷ISBN-13:978-0-7356-2105-3
页数:464

[1a]第250章科索引组织来自第7章。指数内幕和管理

这里是有用的在线copypaste从中
http://sqlserverindexeorgnization.blogspot.com/
虽然没有任何学分源

相关的问题:


更新: @PerformanceDBA,

  • “请忘记你DOCO参考,并再次启动”

什么样的基础上,又开始了我?
任何引用,任何建议。技巧如何重新开始?

  • **“聚集索引始终是更好”

你能回答我的问题Why/when/how is whole clustered index scan chosen rather than full table scan?的疑问是什么,是完全聚集索引扫描的意思。它读取的不是全表扫描吗?

  • “”如果有IAM,那么没有索引”

所以,没有IAM,如果没有索引呢?
有IAM如果有CI?

我怎么验证/研究它
如果所有文档写相反:
- 有IAM在非索引表
- 没有IAM如果出现聚集IND恩。

回答

1

这是很多问题。是的,IAM用于在堆上查找页面。区别在于,如果没有索引,就无法知道对于任何给定数据片段要检索哪些页面。 SQL /关系数据模型的一个重要特征是查询只能通过数据值访问数据 - 而不是直接使用指针或其他结构。

槽号只是标识页面内的一行。行数据在页面内不是逻辑排序的,即使在聚簇索引中也是如此。每个数据页面都包含一个指向页面内行的位置的行偏移表。

由于需要额外的书签查找,聚集索引可能会减慢非聚簇索引的数据访问速度。这可以通过使用INCLUDE子句将列添加到NC索引来缓解。有时,在表上没有聚簇索引可能更有效。

1

请阅读我的回答根据“没有直接访问聚集表中的数据行 - 为什么?“,第一。

如果有IAM,然后有一个指数。

但是,如果没有CI,则该行是在一个堆,是的,如果你想直接读取(没有使用NCI,或者没有指数存在的地方),你只能对表进行堆扫描

聚集索引总是更好,没有一个,有一个例外和一个警告, - 标准条件:

  1. 非唯一CI密钥Th导致溢出页面。关系表必须具有唯一键,所以这不是关系表。通过重载列可以使CI很容易变得独特。一个非唯一的配置文件仍然更好(根据我的其他职位),以使非独特的配置文件比没有配置项。

  2. 单调的关键。通常是一个IDENTITY列。插入行分布在整个数据存储结构中的随机插入(而不是随机的插入)(正常情况下具有“良好”的自然关系密钥),插入的密钥始终位于最后一页。这会导致插入热点,并降低并发性。关系密钥应该是自然唯一的;替代项是总是一个额外的索引。代理只是一个关系表(它是一组非规范化的电子表格,其中的行标识符将它们链接在一起;您不会从数据库中获得数据库的表现力)。 。
    所以常见的建议是,使用NCI作为单调密钥,并确保CI允许良好的数据分布。

负债证明书的优势是巨大的,没有很好的理由,有一个(有可能是如上面提到的不好的原因)。

配置项允许范围查询; NCI不会。但这不是唯一的原因。

另一个需要注意的是,你需要保持CI重点小的宽度,因为它是在NCIS携带。现在通常这不是一个问题,因为宽CI键很好。但是,如果您的电子表格伪装成数据库的Unormalise dbunch会导致比标准化数据库更多的索引,这确实成为一个考虑因素。因此帝国奉献者的忠告是保持CI键的宽度。配置项不会“增加”NCI,这是不准确的。如果你有NCI,那么它会有一个指针或一个CI密钥;如果你有一个CI(具有所有的好处),那么成本是CI密钥而不是RowId,可以忽略不计。所以准确的说法是,增加NCIs。

谁说的CI的顺序访问不能并行化是错误的(MS可以打破它的一个版本,并在接下来的修复它,但这是短暂的)。

使用ANSI SQL ... PRIMARY KEY ...符号默认为唯一的聚集。因为db应该是Relational。独特的PK应该是一个很好的友好的关系密钥,而不是一个白痴的IDENTITY列。因此总是(不包括例外)PRIMARY KEY是聚类的最佳候选者。

你总是可以创造任何你想要的指数通过避免ANSI SQL ... PRIMARY KEY ...符号和使用CREATE [UNIQUE] [CLUSTERED]索引符号来代替。

这是不可能回答你的最后一个问题,你必须不断地问问题,直到你用完。但是,请你忘记你提到的可可,并重新开始,否则我们会在这里讨论明确的知识和gobbledegook之间的区别。

+0

我没有阅读,请参阅我的更新主帖。我会一直问,但不会在同一个线程中,这是违反规则(这不是论坛) – 2010-10-29 13:35:56