一周工作總結 左連線造成的一些問題

2022-02-24 07:13:00 字數 1354 閱讀 9656

今天有同事告訴我,有個sql執行了好久好久執行不出來,我說好就是多久?她說一天左右了。真是令人咋舌的sql。於是我要來了sql看了看執行計畫,確實讓人咋舌。

下圖中就是執行計畫的截圖:

25g的cost和75t的bytes確實是無法承受之重。這個sql是這樣子的:

select部分做了很多sum運算,還有distinct等運算,總之很麻煩,group by部分就是上面的維度。其中最大的表是table3和table4,這兩個表所需要查詢的資料量都在3g以上,各自差不多3000萬資料。

最開始我以為是因為資料量大的原因導致的這個執行計畫不可實現,但是在我將table3和table4的相應資料進行壓縮後,資料量儘管各自降低到了1g左右,但是執行計畫基本上沒有改變,這不是我要的效果,於是我注意到了執行計畫中紅色框中的部分。是不是這裡導致了問題的發生?於是我開始檢視sql,就發現了乙個問題:table4實際上只有201302的資料,但是為什麼這裡還需要在左連線的時候寫上月份標識,這個比較不合理,而且根據我以往的經驗判斷,左連線或者右連線的時候,如果and條件寫的太多,往往會影響執行計畫,導致sql長久的無法得到結果。於是我做了乙個很簡單的事情,就是把table4的month_id部分去掉,後來我又進了一步,將table3的month部分也去掉了,這是乙個分割槽表,於是我用了這個辦法:

left join table3 partition(part_02),這樣即實現了減少and條件的目的,又不會影響資料準確的效果,一舉兩得。在進行了相關的優化之後,執行計畫變成了這個樣子:

可以看到執行計畫發生了翻天覆地的變化,直接能看到的就是少了nested loops outer,取而代之的是圖中1部分和2部分的hash join outer和table1的hash join outer,這是我喜歡看到的事情,我就喜歡看到簡單的執行計畫。雖然這個cost依舊很大,但是我實在不想動彈了,這個的資料量實在是太巨大了,我面對的優化工作難度已經無法讓我有精力想過去那樣,仔細研究思考,然後把cost弄到幾千或者更小的程度了,就這樣吧,天要下雨,娘要嫁人,隨他去吧。

我以前看到論壇上或者書上都在寫,如果你的表超過1g,那麼最好進行分割槽,這句話現在我深有體會,如果沒有分割槽表,這個sql也沒有辦法優化了(或者說我就沒有能力去優化了),因為沒有辦法去掉month的條件,除非是將特定月份的資料取出來建立乙個中間表,不過那麼做似乎有點麻煩了,不符合我一貫喜歡寫短**的習慣。

一周工作總結 左連線造成的一些問題

今天有同事告訴我,有個sql執行了好久好久執行不出來,我說好就是多久?她說一天左右了。真是令人咋舌的sql。於是我要來了sql看了看執行計畫,確實讓人咋舌。下圖中就是執行計畫的截圖 25g的cost和75t的bytes確實是無法承受之重。這個sql是這樣子的 select部分做了很多sum運算,還有...

一周工作總結

一周又過去了,感覺時間過得快,又覺得慢。這不上次寫部落格離現在已經一周了,但上次寫部落格的情景還很清晰,故為快。這過去的幾天比較充實,也許因為這樣覺得時間也慢吧。下面簡要回顧下上週工作吧,做個小總結。上次還認為工作是嵌入式開發,會跟硬體打交道多,對硬體開發平台和軟體開發環境還只是初步了解。根據現在的...

6 28 7 4一周工作總結

這一周是我感到迷茫的一周,原因主要有三個方面 一是同事被開除,二是自己不知道該幹些什麼,三是對自己的未來感到困惑。首先第一點,我以為要開除的人是我,到最後把劉萍給開除了,可能是我平時加班比較多的緣故吧。關於要進行人員調整的事情在之前的一次 會議上已經說了,當時制定的是每乙個人有自己的東西,並且保證在...