深度嵌套子查询因子（CTE）的性能下降

时间：2013-11-05 19:53:26

标签： sql oracle oracle11g benchmarking

此查询包含16个相等的步骤 每一步都在同一数据集（单行）上进行相同的计算，
但最后的步骤需要花费太多时间。 

with t0 as (select 0 as k from dual)
,t1 as (select k from t0 where k >= (select avg(k) from t0))
,t2 as (select k from t1 where k >= (select avg(k) from t1))
,t3 as (select k from t2 where k >= (select avg(k) from t2))
,t4 as (select k from t3 where k >= (select avg(k) from t3))
,t5 as (select k from t4 where k >= (select avg(k) from t4))
,t6 as (select k from t5 where k >= (select avg(k) from t5))
,t7 as (select k from t6 where k >= (select avg(k) from t6))
,t8 as (select k from t7 where k >= (select avg(k) from t7))
,t9 as (select k from t8 where k >= (select avg(k) from t8))
,t10 as (select k from t9 where k >= (select avg(k) from t9))
,t11 as (select k from t10 where k >= (select avg(k) from t10))
,t12 as (select k from t11 where k >= (select avg(k) from t11)) -- 0.5 sec
,t13 as (select k from t12 where k >= (select avg(k) from t12)) -- 1.3 sec
,t14 as (select k from t13 where k >= (select avg(k) from t13)) -- 4.5 sec
,t15 as (select k from t14 where k >= (select avg(k) from t14)) -- 30 sec
,t16 as (select k from t15 where k >= (select avg(k) from t15)) -- 4 min
select k from t16

子查询t10立即完成，但整个查询（t16）需要4分钟才能完成。

Q1。
为什么相同数据的相同子查询的计算时间差别很大？

Q2。
它看起来像一个bug，因为它在Oracle 9上运行速度非常快，在Oracle 11上运行速度非常慢 事实上，每个带有长而复杂的with-clause的select语句都会表现得一样 这是一个已知错误吗？ （我无法访问metalink）
建议使用哪种解决方法？

Q3。
我必须为Oracle 11编写代码，我必须在单个选择语句中完成所有计算 我不能在两个单独的陈述中将我的长篇陈述分开，以加快它的速度 Oracle中是否存在提示（或者可能是一些技巧）以使整个查询（t16）在合理的时间内（例如，在一秒内）完成？我试图找到这样的但无济于事 顺便说一句，执行计划非常好，而且成本表现为步数的线性函数（非指数）。

2 个答案:

答案 0 :(得分：7)

Q1：似乎没有任何关于计算时间的信息，只是优化算法中的错误，它会在计算最佳执行计划时使其生气。

Q2：Oracle 11.X.0.X中存在许多已知和修复的错误，这些错误与嵌套查询和查询因子分解的优化有关。但是很难找到具体的问题。

问题3：有两个未记录的提示：materialize和inline，但在我尝试您的示例时，其中没有一个适合我。服务器配置或升级到11.2.0.3的某些更改可能会增加嵌套with子句的限制：对于我（在11.2.0.3 Win7 / x86上），您的示例工作正常，但嵌套表的数量增加到30挂了一个会话。

解决方法可能如下所示：

select k from (
select k, avg(k) over (partition by null) k_avg from ( --t16
  select k, avg(k) over (partition by null) k_avg from ( --t15
    select k, avg(k) over (partition by null) k_avg from ( --t14
      select k, avg(k) over (partition by null) k_avg from ( --t13
        select k, avg(k) over (partition by null) k_avg from ( --t12
          select k, avg(k) over (partition by null) k_avg from ( --t11
            select k, avg(k) over (partition by null) k_avg from ( --t10
              select k, avg(k) over (partition by null) k_avg from ( --t9
                select k, avg(k) over (partition by null) k_avg from ( --t8
                  select k, avg(k) over (partition by null) k_avg from ( --t7
                    select k, avg(k) over (partition by null) k_avg from ( --t6
                      select k, avg(k) over (partition by null) k_avg from ( --t5
                        select k, avg(k) over (partition by null) k_avg from ( --t4
                          select k, avg(k) over (partition by null) k_avg from ( --t3
                            select k, avg(k) over (partition by null) k_avg from ( --t2
                              select k, avg(k) over (partition by null) k_avg from ( -- t1
                                select k, avg(k) over (partition by null) k_avg from (select 0 as k from dual) t0
                              ) where k >= k_avg
                            ) where k >= k_avg
                          ) where k >= k_avg
                        ) where k >= k_avg
                      ) where k >= k_avg
                    ) where k >= k_avg
                  ) where k >= k_avg
                ) where k >= k_avg
              ) where k >= k_avg
            ) where k >= k_avg
          ) where k >= k_avg
        ) where k >= k_avg
      ) where k >= k_avg
    ) where k >= k_avg
  ) where k >= k_avg
) where k >= k_avg
)

至少它对我的嵌套级别为30，并且与WINDOW BUFFER和VIEW而不是LOAD TABLE AS SELECT，SORT AGGREGATE和{{1}生成完全不同的执行计划}。

<强>更新

  1. 刚刚安装了11.2.0.4（Win7 / 32bit）并根据初始查询进行测试。优化器行为没有任何改变。

  2. 即使使用TABLE ACCESS FULL（未记录的）或inline（已弃用）提示，也不可能直接影响CBO行为。可能是一些Guru知道一些变体，但它对我来说是个绝密（也是谷歌:-)。

  3. 如果主select语句分成一个部分并放入返回一组行的函数（函数返回sys_refcursor或强类型游标），则可以在合理的时间内在一个select语句中执行操作，但它是如果是在运行时构造的查询，则不是选择。

  4. 使用XML的解决方法是可行的，但这种变体看起来像通过屁眼洞移除扁桃体（抱歉）：

    5. RULE

    上述奇怪代码的另一个问题是，此变体仅适用于select extractvalue(column_value,'/t/somevalue') abc from table(xmlsequence(( select t2 from ( select t0, t1, ( select xmlagg( xmlelement("t", xmlelement("k1",extractvalue(t1t.column_value,'/t/k1')), xmlelement("somevalue", systimestamp)) ) from table(xmlsequence(t0)) t0t, table(xmlsequence(t1)) t1t where extractvalue(t1t.column_value,'/t/k1') >= ( select avg(extractvalue(t1t.column_value, '/t/k1')) from table(xmlsequence(t1)) ) and extractvalue(t0t.column_value,'/t/k2') > 6 ) t2 from ( select t0, ( select xmlagg( xmlelement("t", xmlelement("k1",extractvalue(column_value,'/t/k1')), xmlelement("somevalue", sysdate)) ) from table(xmlsequence(t0)) where extractvalue(column_value,'/t/k1') >= ( select avg(extractvalue(column_value, '/t/k1')) from table(xmlsequence(t0)) ) ) t1 from ( select xmlagg(xmlelement("t", xmlelement("k1", level), xmlelement("k2", level + 3))) t0 from dual connect by level < 5 ) ) ) ))) 数据集没有大量行的情况。

答案 1 :(得分：4)

（这不是一个完整的答案。希望这里的信息能帮助其他人提供更好的答案。）

Q1：优化器通过内联所有内容来重写查询。内部语句的大小加倍，每个新的公用表表达式都会快速增长。例如，T15生成一个3,162,172个字符查询。

跟踪陈述的代码：

sqlplus user/pass@orcl

alter session set events '10053 trace name context forever, level 1';

with t0 as (select 0 as k from dual)
,t1 as (select k from t0 where k >= (select avg(k) from t0))
,t2 as (select k from t1 where k >= (select avg(k) from t1))
select k from t2;

exit;


sqlplus user/pass@orcl

alter session set events '10053 trace name context forever, level 1';

with t0 as (select 0 as k from dual)
,t1 as (select k from t0 where k >= (select avg(k) from t0))
,t2 as (select k from t1 where k >= (select avg(k) from t1))
,t3 as (select k from t2 where k >= (select avg(k) from t2))
select k from t3;
exit;

如果比较两个跟踪文件有很多不同之处，但大多数都看起来很小。真正的区别只在于字符串后面的一行：Stmt: ******* UNPARSED QUERY IS *******。如果跟踪较大的查询，请小心打开跟踪文件。并非所有编辑都能处理这么大的问题。 T20文件是250MB！

格式化后第一次跟踪的SQL：

SELECT "T1"."K" "K"
  FROM (SELECT 0 "K"
          FROM "SYS"."DUAL" "DUAL"
         WHERE 0 >= (SELECT AVG(0) "AVG(K)" FROM "SYS"."DUAL" "DUAL")) "T1"
 WHERE "T1"."K" >=
       (SELECT AVG("T1"."K") "AVG(K)"
          FROM (SELECT 0 "K"
                  FROM "SYS"."DUAL" "DUAL"
                 WHERE 0 >= (SELECT AVG(0) "AVG(K)" FROM "SYS"."DUAL" "DUAL")) "T1")

格式化后第二次跟踪的SQL：

SELECT "T2"."K" "K"
  FROM (SELECT "T1"."K" "K"
          FROM (SELECT 0 "K"
                  FROM "SYS"."DUAL" "DUAL"
                 WHERE 0 >= (SELECT AVG(0) "AVG(K)" FROM "SYS"."DUAL" "DUAL")) "T1"
         WHERE "T1"."K" >=
               (SELECT AVG("T1"."K") "AVG(K)"
                  FROM (SELECT 0 "K"
                          FROM "SYS"."DUAL" "DUAL"
                         WHERE 0 >=
                               (SELECT AVG(0) "AVG(K)" FROM "SYS"."DUAL" "DUAL")) "T1")) "T2"
 WHERE "T2"."K" >=
       (SELECT AVG("T2"."K") "AVG(K)"
          FROM (SELECT "T1"."K" "K"
                  FROM (SELECT 0 "K"
                          FROM "SYS"."DUAL" "DUAL"
                         WHERE 0 >=
                               (SELECT AVG(0) "AVG(K)" FROM "SYS"."DUAL" "DUAL")) "T1"
                 WHERE "T1"."K" >=
                       (SELECT AVG("T1"."K") "AVG(K)"
                          FROM (SELECT 0 "K"
                                  FROM "SYS"."DUAL" "DUAL"
                                 WHERE 0 >= (SELECT AVG(0) "AVG(K)"
                                               FROM "SYS"."DUAL" "DUAL")) "T1")) "T2")

Q2：我不会说每个“复杂”公用表表达式的行为都是一样的。我见过更大的CTE。这只是极端的嵌套似乎是问题所在。我在Oracle Support上找不到任何明显的错误。

ThinkJet的代码看起来像是一个很好的解决方案。嵌套内联视图比嵌套公用表表达式更常见。

问题3：可能有一个提示可以防止这种行为，但我不确定它是什么。希望通过显示查询的转换版本，其他人可以猜测如何修复它。

相关问题
最新问题