采用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';

 

其执行计划:

 

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

发现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语句经常出现的问题,那么修改一下如下:

 

 

 

最终优化后的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语句的非关联形式的sql优化 小麦苗(我的网名)就给大家列举这2个例子,大家有什么不懂的可以给我留言,或者加我QQ(642808185)也行。

时间: 2024-09-14 20:23:10

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

采用MERGE 语句的非关联形式提升性能

      今天照例巡查垃圾sql时,发现一个跑了很长时间的sql,且其执行计划也非常的大,这个sql非常可疑,得排查排查:     第一步,照例查询内存中的执行计划: SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('17t226txddfy5',0,'advanced'));   可以看出执行计划的cost花费非常的大,且Predicate Information(即谓语)部分全是filter过滤的,怎么会没有access访问呢???????拿出其

采用MERGE语句的非关联形式提升性能 ---后传

几天前写过一篇关于merge语句的博客,由于工作忙没有关注后续的优化,今天有空了把这个补上吧.... 之前的博客地址:http://blog.itpub.net/26736162/viewspace-1218671/   关于这个sql,我们的同事终于受不了这个sql了,找我来优化,我说这个sql我之前就检测到了的,,所以已经优化好了的,你直接拿过去跑吧,[这里说明一下:由于是job,boss不让停,那没办法,只能等业务人员自己来找我了]由于最近有点忙就没有关注这个sql语句了,今天终于闲暇下来

iostream-求大神将下列递归阶乘用标号以及goto语句用栈的形式转换为非递归语句

问题描述 求大神将下列递归阶乘用标号以及goto语句用栈的形式转换为非递归语句 #include #include #include #include #include using namespace std; stackS; int fact(int n){ S.push(L2,) L0: if(n==0) return 1; L1: return n*fact(n-1); L2: ; }

merge语句导致的ORA错误分析

      最近处理了好几起关于merge导致的问题,其实看到merge语句内心也还是蛮纠结的,这一次还是碰到了问题,简直无语了.       先交代下问题的背景.有一套OLTP环境和OLAP环境需要同步一部分数据,都是在每天的半夜开始,OLAP的库的一个表数据会根据增量的逻辑从OLTP库中同步,有两种方式,一种是OLAP从OLTP中去抓取,另外一种是OLTP推送给OLAP.看起来表达的意思是差不多的,实现起来就是完全不同的风格,即一种主动一种被动,而对于大部分的应用需求来看,还是更倾向于OLA

SQL Server中使用 Merge 语句实现表数据之间的对比同步

表数据之间的同步有很多种实现方式,比如删除然后重新 INSERT,或者写一些其它的分支条件判断 再加以 INSERT 或者 UPDATE 等.包括在 SSIS Package 中也可以通过 Lookup, Condition Split 等多 种 Task 的组合来实现表数据之间的同步.在这里 "同步" 的意思是指每次执行一段代码的 时候能够确保 A 表的数据和 B 表的数据始终相同. 可以通过 SQL Server 中提供的 Merge 语句来实现,并且还可以将操作的细节记录下来.具

非关联外部链接的重要性

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 众所周知,GOOGLE的PAGERANK集页面关键词关联度(TITLE, HEADING, DESCRIPTION, ANCHOR TEXT, ALT TAG, CONTENT, KEYWORD DENSITY/PLACEMENTS, PAGESIZE)和链接 普遍度LINK POPULARITY(INCOMING LINKS,OUTBOUN

递归形式与非递归形式的斐波那契数列的用法分析_C 语言

复制代码 代码如下: <SPAN style="FONT-SIZE: 32px">采用递归形式和非递归形式实现斐波那契数列</SPAN> 复制代码 代码如下: #include "stdafx.h"#include <iostream>using namespace std;//递归形式的斐波那契数列int fibonacciRecursion(int n){ if (n == 1 || n ==2) {  return 1; }

php通过array_merge()函数合并关联和非关联数组的方法_php技巧

本文实例讲述了php通过array_merge()函数合并关联和非关联数组的方法.分享给大家供大家参考.具体分析如下: array_merge()是一个用于合并数组的php函数,后一个数组追加到前一个的结束位置并返回合并后的结果数组. <?php $beginning = 'foo'; $end = array(1 => 'bar'); $result = array_merge((array)$beginning, (array)$end); print_r($result); ?>

merge语句导致的性能问题紧急优化

晚上正在休息的时候,突然收到一封报警邮件. 报警内容: CPU utilization is too high ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: CPU idle time:59.11 % ------------------------------------ 这个报警信息已经非常明确,CPU使用率很紧张了.这台服务器上运行着Oracle和M