我正在做一些测试，我注意到以下几点：
select field1 from table1
当index fast full scan是主键时会导致field1，因此费用较低（在我的情况下是 4690 ），而
select field2 from table1
会导致table access full（field2上没有约束或索引，即使是常规索引，结果也是相同的），成本为 117591
我知道JOIN / WHERE子句中涉及索引/约束时的收益，但在我的情况下没有任何过滤：我不明白为什么PK应该更快，因为无论如何，我正在检索所有行......
是因为它的独特性吗？汤姆说unique index is the same as a conventional index, structurally，这让我想知道为什么选择PK的费用会低于其他任何一栏。
感谢您的启发： - ）
RGDS。
答案 0 :(得分：4)
单列b-tree索引不存储NULL行的数据。因此，如果您在field2上有索引，但field2允许NULL，则Oracle无法对索引进行扫描，而不会冒可能返回错误数据的风险。因此，全表扫描是Oracle为field2中每行检索table1列数据的唯一有效方法。如果向NOT NULL添加field2约束，Oracle应该至少可以考虑对索引进行全面扫描。
当然，优化器是否选择使用索引（以及它最终使用索引分配的成本）将取决于您在索引和表上收集的统计信息。如果您的统计信息不准确，优化程序的成本估算将不准确，因此生成的计划可能效率低下。这就是人们通常被建议谨慎对待甲骨文对计划成本的估计过于谨慎的原因之一 - 如果你正在考虑一个计划，可能是因为你怀疑这是低效的，这应该意味着你不能靠成本。考虑到每个步骤的基数估计值，并根据数据分布确定这些是否有意义，通常情况会好得多。