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

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

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

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

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

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

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

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

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

總結(jié)

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

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