在没有任何索引的情况下，通过IAM（（索引分配图）访问表行 我可以使用IAM以编程方式直接访问行吗？
缺少索引意味着读取特定行的唯一方法是全表扫描读取所有表吗？
为什么IAM不能参与更具体的直接访问？
“如果表是堆（换句话说，它没有聚集索引），则书签是行标识符（RID），它是File＃：Page＃：Slot＃”形式的实际行定位符。 [1A]
没有进一步的槽定义。好吧，其他消息来源告诉Slot＃真的是行号。正确？还是需要与IAM进一步并列才能确定特定行？
现在，聚簇索引的引入意味着不能直接访问任何数据，而只能通过最终的聚簇索引查找或顺序遍历聚簇叶节点。
我是否理解正确引入聚簇索引仅对选择连续相邻（行范围）行并且仅通过聚簇索引键有用？ 集群表还有哪些好处？
我是否正确理解聚集索引引入会严重影响非完全匹配查询的非聚集索引参与的性能优势？没有直接访问，顺序访问不能并行化，非聚集索引增加了聚簇索引键等，对吗？
好吧，我发现群集表格对于非常具体和易于理解的上下文是有意义的，而主键的创建始终默认为群集表格。为什么？
我对聚集索引的理解有什么看法？
[1]
Microsoft®SQLServer™2005内部：存储引擎
作者：Kalen Delaney - （固体素质学习）
...............................................
出版商：微软出版社
发布日期：2006年10月11日
打印ISBN-10：0-7356-2105-5
打印ISBN-13：978-0-7356-2105-3
页数：464
[1a] p.250章节指数组织来自第7章。指数内部和管理
这是有用的在线copypaste从它
http://sqlserverindexeorgnization.blogspot.com/
虽然没有任何信用来源
相关问题：
更新： @PerformanceDBA，
在什么的基础上再次启动我？ 任何参考，任何建议。技术如何重新开始？
你能回答我的问题Why/when/how is whole clustered index scan chosen rather than full table scan?怀疑是全集群索引扫描的含义是什么。它不是读取全表扫描吗？
那么，如果根本没有索引，就没有IAM吗？ 如果有CI，有IAM吗？
我该如何验证/研究它？
如果所有的文档写相反的话：
- 非索引表上有IAM
- 如果存在聚集索引，则没有IAM。
答案 0 :(得分：1)
这是很多问题。是的，IAM用于查找堆上的页面。不同之处在于，如果没有索引，则无法知道要为任何给定数据检索哪些页面。 SQL /关系数据模型的一个重要特征是查询只能通过数据值访问数据 - 绝不会直接使用指针或其他结构。
插槽号只标识页面中的一行。即使在聚簇索引中，行数据也不会在页面内按逻辑排序。每个数据页面都包含一个行偏移表，指向页面中行的位置。
由于需要额外的书签查找，聚簇索引可能会减慢非聚簇索引的数据访问速度。这可以通过使用INCLUDE子句将列添加到NC索引来缓解。有时，不在表上拥有聚簇索引可能更有效。
答案 1 :(得分：1)
请在“无法直接访问群集表中的数据行 - 为什么？”，首先阅读我的回答。
如果有IAM，则有索引。
但是如果没有CI，那么行就在堆中，是的，如果你想直接读取它（不使用NCI，或者没有指数存在），你只能扫描一个堆。< / p>
群集索引总是更好，没有一个。对于异常或不合标准的条件，有一个例外和一个警告：
非唯一CI密钥。这会导致溢出页面。关系表需要具有唯一键，因此这不是关系表。通过重载列可以非常容易地使CI独特。非唯一CI仍然更好（根据我的其他帖子）具有非唯一CI而非CI。
单调键。通常是IDENTITY列。插入的密钥始终位于最后一页，而不是随机插入分布在整个数据存储结构中的行（正常情况下使用“良好的”自然关系密钥）。这会导致插入热点，并降低并发性。关系密钥应该是自然唯一的;代理总是一个额外的索引。仅代理项不是关系表（它是一组非标准化的电子表格，行标识符将它们链接在一起;你不会从中获得数据库的数据）。
。
因此，常设建议是，使用NCI进行单调密钥，并确保CI允许良好的数据分发。
CI的优势是巨大的，没有充分的理由（上面提到可能有不好的理由）。
CI允许范围查询; NCI没有。但这不是唯一的原因。
另一个需要注意的是，您需要保持CI Key的宽度较小，因为它是在NCI中携带的。现在通常这不是问题，因为宽CI键很好。但是，如果你有一个伪装成数据库的电子表格的非规范性数据库，这会产生比标准化数据库更多的索引，这确实成了一个考虑因素。因此，帝国奉献者的常设建议是，保持CI键的宽度。 CI没有“增加”NCI，这没有准确说明。如果你有NCI，那么它将有一个指针或一个CI键;如果您有CI（具有所有好处），那么成本是CI密钥而不是RowId，可忽略不计。所以准确的说法是，胖胖的CI键会增加NCI。
谁说顺序访问CI无法并行化是错误的（MS可能会在一个版本中破解它并在下一个版本中修复它，但这是暂时的）。
使用ANSI SQL ... PRIMARY KEY ...表示法默认为UNIQUE CLUSTERED。因为db应该是Relational。独特的PK应该是一个友好的友好关系密钥，而不是一个愚蠢的IDENTITY列。因此，PRIMARY KEY总是（不计算例外）是聚类的最佳候选者。
您可以通过避免使用ANSI SQL ... PRIMARY KEY ...表示法并使用CREATE [UNIQUE] [CLUSTERED] INDEX表示法来创建所需的索引。
无法回答你的最后一个问题，你必须继续提问，直到你用完为止。但是请忘记你引用的doco并重新开始，否则我们将在这里讨论清楚知识和gobbledegook之间的区别。