软件开发
处女帖！NLJOIN后，cost，io 剧增
处女帖！NLJOIN后，cost，io 剧增
http://www.db2china.net/club/thread-30695-1-1.html
贴过来这个帖子,里面的信息挺全的, 大家一起看看有什么好建议.
http://www.db2china.net/club/thread-30695-1-1.html
贴过来这个帖子,里面的信息挺全的, 大家一起看看有什么好建议.
2同行回答
那个=0的写法容易导致优化器估算出错,int = '0'不容易，char =0很容易，数据类型自动转换能让这个SQL结果正确，但估算错误可能走错计划。
主外键是很关键的,定义以后会看到优化器的作用。那个递归的写法也需要主外键事实上成立，否则，更复杂:( 而且，应该用max和< +逆序索引，贴上去的太随手
当然这种处理多几行、少几行也不怕，反正待会还会查，多了再来个FFNR，应该可以手工pushdown FFNR收起
主外键是很关键的,定义以后会看到优化器的作用。那个递归的写法也需要主外键事实上成立，否则，更复杂:( 而且，应该用max和< +逆序索引，贴上去的太随手
当然这种处理多几行、少几行也不怕，反正待会还会查，多了再来个FFNR，应该可以手工pushdown FFNR收起
浏览416
nljoin后本来cost就会大幅增加。
这里的sort和tablescan是为了让第八步的index fetch 更高效（ordered outer nljoin），
这步不是问题所在。
问题在于想办法把fetch 150 rows 的动作push down下去。
一个办法就是你在这些表上建主外键的constraint，让优化器自己去push down。
还有就是你手工把fetch 150 rows only下压到OMSADM.SO_RET_ORDER的select中。
就是先 select from OMSADM.SO_RET_ORDER fetch 150 rows only再关联。
但是这个得需要满足两个条件：
1.你得连接不会膨胀（从执行计划里看貌似已经满足了） 2.你的连接不会过滤数据。
hczzhong转递归的写法也是条思路，但SQL太复杂。里面那个不等值的子查询改为RETORD_ITEM_ID > TMP.orderItemID 后 fetch 1 rows only 可能好一点。收起
这里的sort和tablescan是为了让第八步的index fetch 更高效（ordered outer nljoin），
这步不是问题所在。
问题在于想办法把fetch 150 rows 的动作push down下去。
一个办法就是你在这些表上建主外键的constraint，让优化器自己去push down。
还有就是你手工把fetch 150 rows only下压到OMSADM.SO_RET_ORDER的select中。
就是先 select from OMSADM.SO_RET_ORDER fetch 150 rows only再关联。
但是这个得需要满足两个条件：
1.你得连接不会膨胀（从执行计划里看貌似已经满足了） 2.你的连接不会过滤数据。
hczzhong转递归的写法也是条思路，但SQL太复杂。里面那个不等值的子查询改为RETORD_ITEM_ID > TMP.orderItemID 后 fetch 1 rows only 可能好一点。收起
浏览455