一周工作總結(jié)–左連接造成的一些問題

今天有同事告訴我，有個(gè)SQL執(zhí)行了好久好久執(zhí)行不出來，我說好就是多久？她說一天左右了。真是令人咋舌的SQL。于是我要來了SQL看了看執(zhí)行計(jì)劃，確實(shí)讓人咋舌。

下圖中就是執(zhí)行計(jì)劃的截圖：

25G的COST和75T的Bytes確實(shí)是無法承受之重。這個(gè)SQL是這樣子的：

select部分做了很多sum運(yùn)算，還有distinct等運(yùn)算，總之很麻煩，group by部分就是上面的維度。其中最大的表是TABLE3和TABLE4，這兩個(gè)表所需要查詢的數(shù)據(jù)量都在3G以上，各自差不多3000萬數(shù)據(jù)。

最開始我以為是因?yàn)閿?shù)據(jù)量大的原因?qū)е碌倪@個(gè)執(zhí)行計(jì)劃不可實(shí)現(xiàn)，但是在我將TABLE3和TABLE4的相應(yīng)數(shù)據(jù)進(jìn)行壓縮后，數(shù)據(jù)量盡管各自降低到了1G左右，但是執(zhí)行計(jì)劃基本上沒有改變，這不是我要的效果，于是我注意到了執(zhí)行計(jì)劃中紅色框中的部分。是不是這里導(dǎo)致了問題的發(fā)生？于是我開始檢視SQL，就發(fā)現(xiàn)了一個(gè)問題：TABLE4實(shí)際上只有201302的數(shù)據(jù)，但是為什么這里還需要在左連接的時(shí)候?qū)懮显路輼?biāo)識(shí)，這個(gè)比較不合理，而且根據(jù)我以往的經(jīng)驗(yàn)判斷，左連接或者右連接的時(shí)候，如果and條件寫的太多，往往會(huì)影響執(zhí)行計(jì)劃，導(dǎo)致SQL長久的無法得到結(jié)果。于是我做了一個(gè)很簡單的事情，就是把TABLE4的month_id部分去掉，后來我又進(jìn)了一步，將TABLE3的month部分也去掉了，這是一個(gè)分區(qū)表，于是我用了這個(gè)辦法：

left join TABLE3 partition(part_02)，這樣即實(shí)現(xiàn)了減少and條件的目的，又不會(huì)影響數(shù)據(jù)準(zhǔn)確的效果，一舉兩得。在進(jìn)行了相關(guān)的優(yōu)化之后，執(zhí)行計(jì)劃變成了這個(gè)樣子：

可以看到執(zhí)行計(jì)劃發(fā)生了翻天覆地的變化，直接能看到的就是少了NESTED LOOPS OUTER，取而代之的是圖中1部分和2部分的HASH JOIN OUTER和TABLE1的HASH JOIN OUTER，這是我喜歡看到的事情，我就喜歡看到簡單的執(zhí)行計(jì)劃。雖然這個(gè)COST依舊很大，但是我實(shí)在不想動(dòng)彈了，這個(gè)的數(shù)據(jù)量實(shí)在是太巨大了，我面對的優(yōu)化工作難度已經(jīng)無法讓我有精力想過去那樣，仔細(xì)研究思考，然后把COST弄到幾千或者更小的程度了，就這樣吧，天要下雨，娘要嫁人，隨他去吧。

我以前看到論壇上或者書上都在寫，如果你的表超過1G，那么最好進(jìn)行分區(qū)，這句話現(xiàn)在我深有體會(huì)，如果沒有分區(qū)表，這個(gè)SQL也沒有辦法優(yōu)化了(或者說我就沒有能力去優(yōu)化了)，因?yàn)闆]有辦法去掉month的條件，除非是將特定月份的數(shù)據(jù)取出來建立一個(gè)中間表，不過那么做似乎有點(diǎn)麻煩了，不符合我一貫喜歡寫短代碼的習(xí)慣。

總結(jié)

以上是生活随笔為你收集整理的oracle左连接数据会对不上吗,一周工作总结–左连接造成的一些问题-Oracle的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。