外键索引使查询速度极慢

Question

我们最近遇到了由于临时表空间溢出而导致查询速度大幅下降的情况。特定查询会导致此问题。

被查询的表 ( table3) 有一个索引 PK、三个带索引的 FK 和三个 FK 上的复合唯一约束。令人反感的查询如下所示：

SELECT ...
  FROM table1 t1, table2 t2, table3 t3
  WHERE t1.abs_id = ?
    AND t3.vgs_id = t1.vgs_id
    AND t3.ai_id > ?
    AND t2.id = t1.t2_id
    AND t2.status = 2
    AND t2.felddimension = 0
    ...

只有实例重启解决了这个问题。即使杀死连接也没有帮助。

经过对FK和索引的进一步调查，结果是t3.ai_id列上的索引导致性能严重下降。禁用此功能后，独特的约束非常快地为查询提供服务。

有问题的部分是AND t3.ai_id > ?（范围扫描）。唯一扫描不会造成任何麻烦。

现在的问题是，一个指数怎么会导致这样的放缓，而且，我该如何调查原因？它根本不适合我。

竞争时间：正常 10 秒，减速 > 2 分钟或永不返回。

编辑 1 (2013-06-05)：根据 Jack Douglas 和 Chris Saxon 的建议，我已经运行了统计数据，然后执行了解释计划，我已经取得了巨大的飞跃。

我已经计算了带和不带索引的模式统计信息。无论索引是否可用，优化器使用 3-field-composite-unique-index 使查询速度极快。

这是 SQL Developer 的解释计划：

到目前为止一切顺利，现在我在查询中添加了使用错误索引的提示，解释计划是：

现在，这是非常缓慢的。但为什么？

Answer 1

CBO 将考虑许多不同的方式来执行您的查询，同时考虑到表和索引的所有索引和统计信息。

如果您禁用某个索引，显然 CBO 就会削减它可能认为涉及该索引的所有计划。

问题实际上归结为：“为什么 CBO 选择了一个糟糕的计划”，首先要考虑的是您的统计数据是否准确反映了数据库中的现实。是这种情况吗？您如何收集统计信息，以及在这些表和索引上的频率？

当且仅当统计数据良好而 CBO 仍在选择一个糟糕的计划时，您需要开始考虑“为什么？”，然后您需要查看计划，尤其是每个步骤的估计基数，看看哪些情况严重。在某些情况下，这是因为标准统计数据无济于事的相关性，但是当你到达它时就跨越那座桥:)