【问题标题】:Full table scan instead of Index range scan lead to peformance issue全表扫描而不是索引范围扫描会导致性能问题
【发布时间】:2011-04-01 07:23:45
【问题描述】:

我们有一个如下所示的合并语句,而不是索引范围扫描,而是进行全表扫描。它一直成功运行到最后,直到更改表后添加了 3-4 个新列,然后开始进行全表扫描。

我们有 7 个相似的表,有相同的更改,即添加了 3-4 列,但是当我们重新构建索引时,它解决了问题,除了一个表。

有人能解释一下吗?

-纳古

【问题讨论】:

  • 您的问题中似乎缺少代码,没有它就无法回答。
  • 也许优化器在给定基数的情况下做出了不错的选择。您是否尝试重新计算表内容的统计信息?使用dbms_stats.gather_schema_stats 或gather_table_stats。

标签: sql oracle oracle11g


【解决方案1】:

尝试收集有关表的统计信息。最好的方法是使用 DBMS_STATS 包中的例程。最简单的做法是简单地调用 DBMS_STATS.GATHER_DATABASE_STATS,不指定任何参数(即对所有参数使用默认值)。然而,这需要一段时间。要收集单个表的统计信息,您可以使用 DBMS_STATS.GATHER_TABLE_STATS。您需要为“ownname”和“tabname”参数提供值;因此,如果您感兴趣的表名为“MY_SCHEMA.MY_TABLE”,则对 DBMS_STATS.GATHER_TABLE_STATS 的调用看起来像

DBMS_STATS.GATHER_TABLE_STATS('MY_SCHEMA', 'MY_TABLE');

此例程还有其他参数,但默认值可以正常工作。

如果数据库仍然坚持对您感兴趣的表进行全表扫描,则可能意味着您的表上没有索引,数据库认为该索引可能有助于满足查询。如果您可以发布您的查询代码并告诉我们您遇到问题的表上有哪些索引,我们可能会提出其他建议。

分享和享受。

【讨论】:

    猜你喜欢
    • 2021-09-04
    • 1970-01-01
    • 1970-01-01
    • 2021-08-12
    • 2021-03-19
    • 2015-10-19
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多