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

0    76    1

👉 本文共约1792个字,系统预计阅读时间或需7分钟。

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

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

](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';

img

其执行计划:

img

执行计划的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语句的关联形式看看情况:
img

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

发现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;

发现报错:

img

看来有非唯一行,这个是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;

优化后的执行计划:

img

跑一下呢?

img

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

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

18 − 7 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部