1.盡量不要使用select * from，雖**簡單，但會增加資源的使用，觸發或依賴有變動時候，須核准字段；
2.除非是必要的計算，否則儘量減少使用函式；
3.distinct，使用邏輯簡單，但會全表掃瞄，如果是大表的情況下，有索引，盡量不使用distinct；
4.多個union all 的使用，可以分寫幾個insert into，速度更快；
5.如果計算比較複雜，寫在1個查詢或建表語句中會導致速度變慢，語法錯誤的概率也會大大增加，可以分多個中間表計算；
6.查詢時只讀取需要的字段和需要的分割槽；
7.join操作時，做為主表進行關聯，速度更快；
8.多張表join時，盡量保持key相同；
9.大表建立索引時候，可以提高查詢效率，但插入或更新資料時，需要維護索引，降低效率，也會占用儲存空間；
10.後續補充；
造成的不良影響：花費的時間長，失去了分布式計算的優勢，資源分配不均，不能夠負載均衡，小塊的資料快速跑完，大塊的資料由於資源不足而掛掉，導致整個任務失敗。
在spark中的表現：某個stage的有幾個task跑得比大部分task都慢很多。
資料傾斜的幾種方式：分割槽不均導致某幾個分割槽對應的key太多；單個key對應的資料量太多；單條記錄資料太大。
解決方法：
1.增加並行度，設定shuffle的並行度，大部分情況都使用這個，也可以在傾斜的stage之前使用reparation重分割槽；
2.處理特殊case，比較常見，傾斜的key可通過group by key進行count尋找，一般是空值、空字串、還有特別熱點的key，處理方式看業務需求；
3.利用小trick打散key，針對單個key對應的資料量太多，可在key上加隨機字首或字尾將乙個key變成多個key先進行一次shuffle，最後再還原回來；
4.自定義分割槽方案，看當前的業務允不允許了，選分塊更均勻的分割槽，可減少資料傾斜的可能。
mysql資料傾斜 Hive SQL 資料傾斜總結
在海量資料下的資料查詢中，資料傾斜是乙個很恐怖的場景。常常看似很普通的資料查詢，執行了幾個小時也沒有結果，其原因往往是發生了資料傾斜。如果真對資料傾斜採取相應的解決方法，那麼查詢效率將會大大提高。所以，分析資料傾斜是一件相當有意義的任務。本文總結不同情況下的資料傾斜，並分別給出解決方法。資料傾斜 資...
資料傾斜優化
資料傾斜 在分布式程式分配任務的時候，任務分配的不平均。資料傾斜，在企業開發中是經常遇到的，以及是非常影響效能的一種場景。資料傾斜一旦發生，橫向拓展只能緩解這個情況，而不能解決這個情況。如果遇到資料傾斜，一定要從根本上去解決這個問題。而不是想著加機器來解決。方案一用前面講過的map join smb...
mr資料傾斜優化
資料傾斜是資料中的常見情況。資料中不可避免地會出現離群值 outlier 並導致資料傾斜。這些離群值會顯著地拖慢mapreduce的執行。常見的資料傾斜有以下幾類 資料頻率傾斜 某乙個區域的資料量要遠遠大於其他區域。資料大小傾斜 部分記錄的大小遠遠大於平均值。在map端和reduce端都有可能發生資...