Performance 为什么选择pk列比选择非索引列快？

我目前正在做一些测试，我注意到以下几点：

select field1 from table1

当

field1

是主键时，将导致

索引快速全扫描

，因此成本较低（在我的例子中是4690），而

将导致一个

表访问完整

（对

字段2

没有约束或索引，但即使使用常规索引，结果也是一样的），成本为117591

我知道在JOIN/WHERE子句中涉及索引/约束时会有好处，但在我的例子中没有任何过滤：我不明白为什么PK应该更快，因为无论如何，我正在检索所有的行

是因为它的独特性吗？Tom说a，这真的让我想知道为什么选择PK的成本比任何其他专栏都要低

感谢您的启发：-）

---

rgds。

单列b树索引不存储空行的数据。因此，如果您在

field2

上有索引，但

field2

允许

NULL

，Oracle无法在索引上进行扫描，否则可能会返回不正确的数据。因此，完整表扫描是Oracle检索

表1

中每一行的

字段2

列数据的唯一有效方法。如果在<代码>字段2中添加一个<代码>非null <代码>约束，Oracle应该至少可以考虑对索引进行全扫描。< /P>

---

当然，优化器是否选择使用索引（以及它最终分配给使用索引的成本）将取决于您在索引和表上收集的统计数据。如果您的统计数据不准确，那么优化器的成本估算将不准确，因此生成的计划可能效率低下。这也是人们通常被建议谨慎对待甲骨文对计划成本估算的过度信任的原因之一——如果你在看一个计划，很可能是因为你怀疑它效率低下，这意味着你不能依赖成本。通常，最好查看每个步骤的基数估计值，并确定这些估计值在数据分布情况下是否合理。

单列b树索引不会存储空行的数据。因此，如果您在

field2

上有索引，但

field2

允许

NULL

，Oracle无法在索引上进行扫描，否则可能会返回不正确的数据。因此，完整表扫描是Oracle检索

表1

中每一行的

字段2

列数据的唯一有效方法。如果在<代码>字段2中添加一个<代码>非null <代码>约束，Oracle应该至少可以考虑对索引进行全扫描。< /P>

---

当然，优化器是否选择使用索引（以及它最终分配给使用索引的成本）将取决于您在索引和表上收集的统计数据。如果您的统计数据不准确，那么优化器的成本估算将不准确，因此生成的计划可能效率低下。这也是人们通常被建议谨慎对待甲骨文对计划成本估算的过度信任的原因之一——如果你在看一个计划，很可能是因为你怀疑它效率低下，这意味着你不能依赖成本。通常，您最好查看每个步骤的基数估计值，并根据您的数据分布确定这些估计值是否合理。

我明白了，谢谢。因此，您的意思是，在我在示例中使用的简单选择上下文中，任何非空列（未索引）都应该给我与PK select相同的好结果？@Sebas-如果该列被delclared

not null

，并且该列上有索引，您应该获得同等的性能，因为Oracle只需从索引中读取数据而无需点击表即可满足查询。我仍然感到困惑，因为索引没有加载到内存中或类似的内容中，如果行被索引或未被索引，为什么返回所有行会更快？如果我们必须排序，请执行一些联接。。。好的，但是仅仅是检索数据，残酷地说，它为什么会更快呢？？？@Sebas-如果Oracle可以通过读取索引来回答查询，那么它会更快，因为索引在物理上比表小。如果Oracle可以避免从表中读取任何块，而只从索引中读取较小数量的块。一般来说，缓存特定索引块的可能性比缓存特定表块的可能性稍高，但这是次要因素——需要读取的块数的减少是主要因素。我明白了，谢谢。因此，您的意思是，在我在示例中使用的简单选择上下文中，任何非空列（未索引）都应该给我与PK select相同的好结果？@Sebas-如果该列被delclared

not null

，并且该列上有索引，您应该获得同等的性能，因为Oracle只需从索引中读取数据而无需点击表即可满足查询。我仍然感到困惑，因为索引没有加载到内存中或类似的内容中，如果行被索引或未被索引，为什么返回所有行会更快？如果我们必须排序，请执行一些联接。。。好的，但是仅仅是检索数据，残酷地说，它为什么会更快呢？？？@Sebas-如果Oracle可以通过读取索引来回答查询，那么它会更快，因为索引在物理上比表小。如果Oracle可以避免从表中读取任何块，而只从索引中读取较小数量的块。通常，缓存特定索引块的可能性也比缓存特定表块的可能性稍高，但这是一个辅助fa

select field2 from table1