索引组织表（IOT）是存储在索引结构中的表。而表存储 在堆中没有组织，IOT中的数据被存储并按主键排序（数据是索引）。 IOT的行为就像“常规”表一样，并且您使用相同的SQL来访问它们。
适当的关系数据库中的每个表都应该有一个主键...如果我的数据库中的每个表都有一个主键，我应该总是使用索引组织表吗？
我猜答案是否定的，那么什么时候索引组织表不是是最佳选择？
答案 0 :(得分：19)
基本上，索引组织表是没有表的索引。因此，如果您的表的列由主键和最多一个其他列组成，那么您可能有INDEX ORGANIZED的候选者。
但是如果您发现自己正在考虑在非主键列上需要额外的索引，那么您可能最好使用常规堆表。因此，由于大多数表可能需要额外的索引，因此大多数表不适合IOT。
在实践中，索引组织表最有可能是参考数据，代码查找事务。应用程序表几乎总是只有堆组织。
答案 1 :(得分：13)
我认为它们适用于非常窄的表（例如用于解析多对多表的连接表）。如果（几乎）表中的所有列都将在索引中，那么为什么不使用IOT。
如Richard Foote here
所讨论的，小桌子可以成为物联网的理想候选人答案 2 :(得分：9)
我认为以下几种表格是物联网的最佳候选者：
答案 3 :(得分：8)
来自Oracle Concepts指南：
来自AskTom的这个 question也可能有一些兴趣，特别是当有人提供场景然后要求IOT比堆组织表更好的时候，Tom的回答是：索引组织表非常有用 必须存储相关的数据 在一起或数据必须是物理的 以特定顺序存储。这个类型 表通常用于提供信息 检索，空间（见“概述”） Oracle Spatial“）和OLAP 应用程序（参见“OLAP”）。
我们可以整天假设，但是 直到你测量它，你永远不会 知道肯定。
答案 4 :(得分：1)
如果您只通过密钥，整个密钥以及密钥访问该表中的数据，那么索引组织表通常是一个不错的选择。
此外，关于其他数据库功能可以和不能与索引组织表一起使用的内容存在许多限制 - 我记得在至少一个版本中，不能使用具有索引组织表的逻辑备用数据库。如果索引组织表阻止您使用其他功能，则它不是一个好的选择。
答案 5 :(得分：0)
所有IOT真正保存的是表段上的逻辑读取，并且由于您可能在IOT /索引上花费了两个或三个或更多，除了小数据集之外，这并不总是很好的保存。 / p>
加速查找的另一个特性，特别是在较大的表上，是一个单表哈希集群。正确创建它们对于大型数据集比对IOT更有效，因为它们只需要一个逻辑读取来查找数据，而IOT仍然是需要多个逻辑i / o来定位叶节点的索引。
答案 6 :(得分：-1)
我无法对IOT进行评论，但是如果我正确地阅读它，那么它们与SQL Server中的“聚簇索引”相同。通常，如果您的主键（或者如果它不是主键，那么您正在编制索引的值）可能会相当随机地分发，那么您应该考虑不使用这样的索引 - 因为这些插入可能导致许多页面拆分（昂贵的）。
标识列（Oracle中的序列？）和当前日期周围的日期等索引倾向于为这些索引提供良好的候选者。
答案 7 :(得分：-3)
索引组织表 - 与普通表相比 - 有自己的结构，存储和索引数据的方式。
索引组织表（IOT）是实际保存正在编制索引的数据的索引，与存储在其他位置并且具有实际数据链接的索引不同。