吓人的执行计划，但实际运行没那么差

eagle_fan

实际的数据量应该没这么大

加hint /*+ gather_plan_statistics */

然后

select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

可以看到实际的执行时间和buffer gets, physical reads

那个hash join不是笛卡尔乘积，下面Predicate Information写的很清楚是TR.A=TH.A

anlinew

估计CBO是按SURVEYOBJECTID的选择性算的
实际上是substrb(SURVEYOBJECTID,3,2) distinct count100左右 实际31  rows

zhoujiongfield

难怪执行情况还可以

bitizerg

因为你在HASH JOIN后结束了，没有遇到问题

如果有2个类似的
比如

with xxx as
(你的sql),
with xxy as
(你的sql2)
select .... from xxy,xxx

就出问题了

尝试下nest loop or

optimizer_mode =first_rows_100 试试

kelsoncong

这个执行计划太帅了!!!!

kelsoncong

不过真正的读操作到不是很多,前一段时间一直纠结在一个看上去执行计划值很小,但实际要跑5个多小时的sql上,后来调整了索引,执行计划变大了以后,实际运行速度反而缩短了很多.
搞的我现在对所有执行计划的准确性产生了极大的怀疑...