database - 为什么oracle建立了表索引却还要全表扫描？

Question

我有一个包含 3000K 行的表“MSATTRIBUTE”。我使用以下查询来检索数据，此查询具有不同的执行计划，具有相同的数据库数据但在不同的环境中。在一个环境中，它看起来是全表扫描，所以查询非常慢，但在另一个环境中，它都使用索引扫描，这很好，每个人都知道为什么它在一个环境中有全表扫描，因为我为他们建立了索引，我该怎么做就像我在 env 1 中测试的那样，让索引扫描成为索引扫描。我该如何改进这个查询？

Answer 1

如果不了解您的数据模型和您的业务，就很难给出具体的积极建议。但这里有一些关于您的索引策略的注释，以及为什么我猜优化器没有使用您拥有的索引。

在子查询中，从三列访问 REDLINE_MSATTRIBUTE 驱动器的路径:

• 类(class)
• OBJECT_ID
• CHANGE_RELEASE_DATE。

CLASS 未编入索引。但这大概不是很有选择性。对象 ID是复合索引的前导列，但其他列与子查询无关。

但最大的问题是 CHANGE_RELEASE_DATE。这根本没有索引。这是个坏消息，因为您的一个主键查找会生成一个日期，然后将其与 CHANGE_RELEASE_DATE 进行比较。如果列没有索引，数据库必须读取表以获取其值。

主查询驱车

• 注意
• CHANGE_ID
• OBJECT_ID(再次)
• CHANGE_RELEASE_DATE(再次)
• (再次)上课
• OLD_VALUE

ATTID 已编入索引，但该索引的选择性如何？优化器可能认为它不是很有选择性。 ATTID 也在具有 CHANGE_ID 和 OLD_VALUE 的复合索引中，但它们都不是前导列，因此这不是很有用。我们已经讨论了 CLASS、CHANGE_RELEASE_DATE 和 OBJECT_ID。

只有当索引比表扫描更便宜(读取更少)时，优化器才会选择使用索引。这通常意味着 WHERE 子句条件需要映射到索引的前导(即最左边)列。这可能是子查询中 OBJECT_ID 和 ATTID 的情况，除了

1. 执行计划必须执行 INDEX SKIP SCAN，因为 REDLINE_MSATTRIBUTE_INDEX1 在两列之间有 CHANGE_ID
2. 无论如何，数据库都必须访问表以获取 CLASS 和 CHANGE_RELEASE_DATE。

因此，您可以通过在 (CHANGE_RELEASE_DATE, CLASS, OBJECT_ID, ATTID) 上构建索引来获得一些改进。但正如我前面所说，在不了解您的情况的情况下，这些只是不明智的猜测。