貌似可以用merge into merge into A using B@Url on (a.contentid = b.contentid) when matched then update set a.createtime = b.createtime when not matched then insert values (b.contentid, b.createtime)
----没测试 merge into A using B@Url on (a.contentid = b.contentid) when matched then update set a.createtime = b.createtime when not matched then insert values (b.contentid, b.createtime)
merge into A
using B@Url
on (a.contentid = b.contentid)
when matched then
update set a.createtime = b.createtime
when not matched then
insert values (b.contentid, b.createtime)
----没测试
merge into A
using B@Url
on (a.contentid = b.contentid)
when matched then
update set a.createtime = b.createtime
when not matched then
insert values (b.contentid, b.createtime)
减小重做日志,因为维护索引需要产生大量的重做日志.
2. beckhamboo和我提出的方案都是可行的,只是角度不同而已。
对表进行分区是处理大数据的好方案之一。单纯从sql的角度
来看问题,虽然能解决目前的问题,但是随着表的数据量的增长,
肯定会引发新的问题。因此,我个人认为解决诸如大数据量的更新,
删除等比较现实的问题时,先优化存储结构是必须要考虑的。
3. "写from的时候,数据量大的表要放在前,小的放在后"这条原则
只是在优化器模式为rbo时有效,如果为cbo,它会自己评估查询代价.