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