一个表A里面有90多万条数据,现在每天我晚上跑批处理时需要对这个表进行更新操作,需要花费很长时间,经调查发现下面的现象
ID为表A的主键,ID是通过SYS_GUID()生成的,另外有时间procdate和分行branch,update语句的下面三种写法,为什么执行时间会是这种结果呢?
sql1
update a t set t.col1 = .. ,t.col2 = .. where trim(t.id) = ........
执行费时:1.67秒sql2
update a t set t.col1 = .. ,t.col2 = .. where trim(t.id) = .. and t.procdate = to_date('2008-09-30','yyyy-MM-dd') and trim(t.branch) = ....
执行费时:0.35秒sql3
update a t set t.col1 = .. ,t.col2 = .. where t.procdate = to_date('2008-09-30','yyyy-MM-dd') and trim(t.branch) = .... and trim(t.id) = ..
执行费时:0.25秒哪位高人解释一下啊,谢谢
ID为表A的主键,ID是通过SYS_GUID()生成的,另外有时间procdate和分行branch,update语句的下面三种写法,为什么执行时间会是这种结果呢?
sql1
update a t set t.col1 = .. ,t.col2 = .. where trim(t.id) = ........
执行费时:1.67秒sql2
update a t set t.col1 = .. ,t.col2 = .. where trim(t.id) = .. and t.procdate = to_date('2008-09-30','yyyy-MM-dd') and trim(t.branch) = ....
执行费时:0.35秒sql3
update a t set t.col1 = .. ,t.col2 = .. where t.procdate = to_date('2008-09-30','yyyy-MM-dd') and trim(t.branch) = .... and trim(t.id) = ..
执行费时:0.25秒哪位高人解释一下啊,谢谢
现在版本里条件顺序没关系?没听说过
对楼主的oracle一定是有关系的
第一句条件只有一个,过滤得很少,所以耗时最长
2和3 除了条件顺序,其他的完全一样
The cost based optimizer(CBO) is rather insensitive to the ordering of where clauses, it assigns costs in order to determine what to do first and how to do things. The old unsupported rule based optimizer(RBO) was sensitive to the ordering, but not so the CBO.
在 pl/sql developer中可以很简单的看执行计划,按一下F5就出来了
然后where条件是从后往前的,id应该是过滤的最多的条件。因此。。
跟SQL Tuning有关的问题,这两个条件很重要的。
不知道的话,会出现很多版本的回答,你又不能说不对。
wildwave的回答在RBO上是很对的。CBO上也有这种情况,当你没用绑定变量,你得统计信息不准确的时候就有可能,我就在10G/CBO上碰上过,顺序跟执行计划。后来用绑定变量,重新统计一下统计信息就不出现了。最好是看看这三个语句的执行计划,然后优化一下的SQL或者,改一下你的索引。
90万条数据来说,你得SQL语句,写得真的很或者说设计的有问题。