采用merge语句的非关联形式再次显神能

 


采用merge语句的非关联形式再次显神能


题记:采用merge语句的非关联形式确实可以提高update语句的性能,尤其对于百万级别的数据量,之前的一个关于merge语句的优化案例请参考:

http://blog.itpub.net/26736162/viewspace-1218671/



 

今天发现一个update的更新sql语句跑了1天多的时间了,又是单纯的update语句,作为优化工作的我对这种事情肯定不能忍受的,看官请看图:

select a.SQL_ID,a.SQL_TEXT,a.ELAPSED_TIME2,a.SESSION_TYPES from XB_SQL_MONITOR_LHR a where a.SQL_ID='aaqkudujcm4jp';

采用merge语句的非关联形式再次显神能

 

其执行计划:

 

采用merge语句的非关联形式再次显神能

执行计划的cost花费有点大哟,,,,

 

原sql语句:

 

UPDATE zhui_car_ins_140717_v2 a

SET a.date_of_open =

(SELECT b.date_opened

FROM riskdw.mid_acct_sum b

WHERE a.party_no = b.party_no);

 

O()︿︶)o 唉,,,,,,这什么垃圾sql呢?????连个where子句都没有。。。。。。。,然后发现有全表扫描,看了下sql里边设计到非索引列,根据业务,非索引列经常随着索引列出现,那么就建立联合索引咯。。。。。,,,,然后再修改为merge语句来更新表:

create index ind_mid_acct_partyno on riskdw.mid_acct_sum(party_no,DATE_OPENED) PARALLEL 20 NOLOGGING;

alter index ind_mid_acct_partyno NOPARALLEL;

 

 

先修改为merge语句的关联形式看看情况:
采用merge语句的非关联形式再次显神能


发现cost花费依然有点高,好吧再优化优化,然后再修改为merge语句的非关联形式来更新表:

 

再次执行:

MERGE INTO RISKPUBZCZH.zhui_car_ins_140717_v2 t

USING (SELECT a.rowid AS rowids,

b.date_opened date_opened

FROM riskdw.mid_acct_sum b,

RISKPUBZCZH.zhui_car_ins_140717_v2 a

WHERE a.party_no = b.party_no ) t1

ON (t.rowid = t1.rowids)

WHEN MATCHED THEN

UPDATE SET t.date_of_open = t1.date_opened;

COMMIT;

发现报错:

采用merge语句的非关联形式再次显神能

看来有非唯一行,这个是merge语句经常出现的问题,那么修改一下如下:

 

 

 

最终优化后的sql:

MERGE INTO RISKPUBZCZH.zhui_car_ins_140717_v2 t

USING (SELECT a.rowid AS rowids,

MAX(b.date_opened) date_opened

FROM riskdw.mid_acct_sum b,

RISKPUBZCZH.zhui_car_ins_140717_v2 a

WHERE a.party_no = b.party_no

             group by A.ROWID ) t1

ON (t.rowid = t1.rowids)

WHEN MATCHED THEN

UPDATE SET t.date_of_open = t1.date_opened;

COMMIT;

 

优化后的执行计划:

采用merge语句的非关联形式再次显神能

 

跑一下呢?

采用merge语句的非关联形式再次显神能

 

 

尼玛,,,,,这么快,,,,,又是自行车到宇宙飞船的速度的转变呀。。。。。。。

 

 

结尾: 有关merge语句的非关联形式的sql优化 小麦苗(我的网名)就给大家列举这2个例子,大家有什么不懂的可以给我留言,或者加我QQ(642808185)也行。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-1222423/,如需转载,请注明出处,否则将追究法律责任。