查询效率：格式塔效果不好；快速零件

Question

我的查询的结构是针对一个非常强大的大型数据库的3个联接子查询。数据库将“较旧的”数据发送到存档模式，而无需对数据结构进行任何更改。因此，根据我调查的主题的年龄，我的查询可能指向存档模式或生产模式表。当我对存档架构运行查询时，它将在大约一分钟内运行。当我遇到生产问题时，一个小时后仍无法完成。

令人困惑的是，查询的生产版本解释计划表明它比归档版本更有效。

查询的形式基本上是：

SELECT 
  SUB1.*,
  SUB2.*,
  SUB3.*
FROM ( BLAH BLAH BLAH ) SUB1
JOIN ( BLAH BLAH BLAH ) SUB2 ON SUB1.FIELD_11 = SUB2.FIELD_21
JOIN ( BLAH BLAH BLAH ) SUB3 ON SUB1.FIELD_12 = SUB3.FIELD_31
                           AND  SUB2.FIELD_22 = SUB3.FIELD_32
;

参考正式版：

当我仅运行子查询SUB1时，它将在1.22秒内返回468行。

当我仅运行子查询SUB2时，它在.44秒内返回807行。

当我仅运行子查询SUB3时，它在27秒内返回63,106行。

在SUB3 JOIN语句中使用的两个字段都是组成SUB3子查询的单个表中的两个索引字段。

数据库非常强大。

为什么查询会相对较快地部分运行-在一起运行时却很慢。如果我拥有数据库权限，则可以将每个子查询写入临时表并运行3部分连接，并希望它在不到一秒钟的时间内运行。引擎为什么不这样做？

编辑： 这是解释计划。

编辑： 这是查询的归档架构版本的说明计划（架构名称相同，但表数据实际不同）。该查询将在大约一分钟内运行，并按预期返回几千行。根据解释计划，这似乎要贵得多-怎么可能？

Answer 1

我将连接顺序从1,2,3更改为2,1,3。这允许查询运行并完成（第一次）。

我不知道为什么，所以我不会接受这个解决方案。