存储过程中的sql语句执行慢,请看一下是否可以优化

显示全部楼层 · 2016-2-2 09:36:33

update t_tablename
set aTh2=null
where (aCustomerCode,aTh2) in
(select aCustomerCode,aDoNotCallNum from tDoNot where aType'02');
用in肯定慢,可以改为a.aCustomerCode=b.aCustomerCode的sql吗?

千问 · 2016-2-2 09:36:33

update t_tablename t
set aTh2=null
where exist (select * from tDoNot d wheret.aCustomerCode=d. aCustomerCode and t.aTh2=d.aDoNotCallNum and d.aType'02')

测试一下，应该是这么写

千问 · 2016-2-2 09:36:33

ok, 谢谢了

千问 · 2016-2-2 09:36:33

可以了么？
楼主马甲暴露了

千问 · 2016-2-2 09:36:33

最初由 diablo2 发布
[B]update t_tablename t
set aTh2=null
where exist (select * from tDoNot d wheret.aCustomerCode=d. aCustomerCode and t.aTh2=d.aDoNotCallNum and d.aType'02')

测试一下，应该是这么写 [/B]
为什么。。。

千问 · 2016-2-2 09:36:33

原来的方法应该是生成一个较大的temp table，然后对每一行的数据再里面找。
新的方法把它化作join，判定结果集是否存在

千问 · 2016-2-2 09:36:33

可以了!
很少用exists语句,外小内大的sql用exists速度快,外大内小的sql用in快!
又学了一招,谢了

千问 · 2016-2-2 09:36:33

最初由 wangzhonnew 发布
[B]原来的方法应该是生成一个较大的temp table，然后对每一行的数据再里面找。
新的方法把它化作join，判定结果集是否存在 [/B]
ORACLE两种方式都能处理成join。。。。

千问 · 2016-2-2 09:36:33

db2也可以，譬如INLIST_TO_NLJN参数
不同的是优化器在做huristic的时候有可能用到IN也有可能JOIN
但是exist效率比IN高，在这个case里最关键的应该还是temp table的大小。
在楼主的case里，temp table应该是很大的，然后不管是用什么方法所需要的开销都是很大的。
而大菠萝的例子能够使用更多的predicate减少temp table的体积，这个俺觉得应该才是大菠萝兄的思路。
大菠萝请确认一下哈

千问 · 2016-2-2 09:36:33

最初由 wangzhonnew 发布
[B]db2也可以，譬如INLIST_TO_NLJN参数
不同的是优化器在做huristic的时候有可能用到IN也有可能JOIN
但是exist效率比IN高，在这个case里最关键的应该还是temp table的大小。
在楼主的case里，temp table应该是很大的，然后不管是用什么方法所需要的开销都是很大的。
而大菠萝的例子能够使用更多的predicate减少temp table的体积，这个俺觉得应该才是大菠萝兄的思路。
大菠萝请确认一下哈 [/B]
现在版本的ORACLE的优化器下IN跟exist表现一样
也就是说就算用IN，优化器依然可以用外表驱动IN子句里的内表
能不能把DB2下两种方式的执行计划发上来对比看一下？