在试验中尝试了2种更新数据的方法:
1.update table set ... where ...
2. 先根据更新条件创建临时表,再删掉未更新之前的表,最后把临时表更名为原始表名
通过试验很明显的可以认识到update的效率是非常之低的。通过在网上跟其他oracle用户的讨论,也都一致的认为,大数据量更新应该采用第二种方法
被更新的表名:test_mt_sms
数据量:1500w左右(具体数字搞忘了)
待更新的数据量:7151773
采用第一种方法:
更新语句:
update test.test_mt_sms t1 set channel_code='$channel_code',sub_channel_code='$sub_channel_code' where #service_id='$service_id' and RECV_ADDRESS='$user_name'
这个sql从22:24跑到第二天上班都还没完。。。几乎是一个不可完成的任务了。
采用第二种方法:
创建临时表的sql语句:
create table test. tmp_mt_sms
tablespace tbs_sub
as
select
t1.MISC_MSG_ID,
t1.MSG_ID,
t1.MSG_TYPE,
t1.FEE_TYPE,
t1.FEE_VALUE,
t1.SEND_ADDRESS,
t1.RECV_ADDRESS,
t1.FEE_ADDRESS,
t1.DOWN_STATION,
t1.OUTTER_ID,
t1.SERVICE_ID,
t1.OSS_RECV_CODE,
t1.MT_TYPE,
t1.MT_CONTENT,
t1.MT_TIME,
t1.CARRY_MSG,
t1.CARRY_ID,
decode(t3.link_id,null,t2.channel_code,'WEB') channel_code,
t2.SUB_CHANNEL_CODE,
t2.REG_MODE,
t2.UNREG_MODE,
t2.ENABLE_STATUS,
t2.FIRST_REG_TIME,
t2.LAST_REG_TIME,
t2.LAST_UNREG_TIME,
t1.RPT_FLAG,
t1.RPT_STATE,
t1.GATEWAY_RPT_STATE,
t1.link_id,
t1.err_detail
from test.tmp_oicall_info_20070206 t1
left join test.tmp_sso_mt
t3
on t3.stat_date=to_date('2007-02-06', 'YYYY-MM-DD')
and t3.link_id = t1.link_id
left join
test.tmp_user_info t2
on t2.user_num = t1.RECV_ADDRESS
and t1.service_id = t2.service_id
/////////////////////////# Elapsed: 00:13:05.74//////////////////////////
再加上drop table 和rename table ,总耗时稳定在20分钟之内
通过这个试验,很明显的深刻的认识到了update的低效,所以对大数据量更新一定要慎重的使用update