盡量盡早地過濾資料，減少每個階段的資料量，對於分割槽表要加分割槽。
案例一：
-- 案例一：
select a.
key,a.col1,a.col2,b.col3,b.col4
from
a a
left
outer
join
b b
on a.
key= b.
keyand a.dt=『20150101』 and b.dt=『20150101';
--優化方法一： 使用where，盡早分割槽
select a.
key,a.col1,a.col2,b.col3,b.col4
from
a a
left
outer
join
b b
on a.
key= b.
keywhere a.dt=『20150101』 and b.dt=『20150101';
select a.
key,a.col1,a.col2,b.col3,b.col4
from
(select
key,col1,clo2 from a where dt =
'20150101'
)aleft
outer
join
(select
key,col3,clo4 from b where dt=
'20150101'
)b
on a.
key= b.
key
map數的決定因素有：（1）input的檔案總個數（2）input的檔案大小（3）集群設定的檔案快大小（blocksize預設為64m）（4）maxsize(mapred.max.split.size)
splitsize的計算公式：max}，其中minsplitsize大小預設為1b，maxsize為mapred.max.split.size的值。
2. map數的計算方式
單個檔案：檔案大小/splitsize>1.1，建立乙個split0，檔案剩餘大小=檔案大小-splitsize…剩餘檔案大小/splitsize<=1.1 將剩餘的部分作為乙個split每乙個分片對應乙個map任務。總map數：每個檔案的map數之和。
2.3 調整map數
通過設定引數，來合併map輸入的小檔案：set hive.input.format=org.apache.hadoop.hive.ql.io.combinehiveinputformat; ##執行map前進行小檔案合併set mapred.max.split.size=128000000; ##每個map最大輸入大小注：mapred.map.tasks設定map個數無效。
2.4 調整reduce數
不指定reducer個數的情況下，hive會猜測確定乙個reducer個數，基於以下兩個設定： 引數1：hive.exec.reducers.bytes.per.reducer（每個reduce處理的資料大小，預設為1g） 引數2 ：hive.exec.reducers.max（每個job使用的最大reduce個數，預設為999）計算reducer數的公式：n=min(引數2，總輸入資料量/引數1)通過設定這兩個引數來減少或增加reduce數，案例：set hive.exec.reducers.bytes.per.reducer=256000000;##每個reduce處理的資料大小set mapred.reduce.tasks=10;##設定reduce個數set hive.exec.reducers.max=2000;##增加最大reduce個數
hive對union all 優化只侷限於非巢狀查詢
案例二：
-- 案例二：
select
*from
(select
*from t1 group
by c1,c2,c3
union
allselect
*from t2 group
by c1,c2,c3
)t3 group
by c1,c2,c3
select
*from
(select
*from t1
union
allselect
*from t2
)t3group
by c1,c2,c3
4.1無效數值取值過多
常用方法：將無效的資料轉換為隨機數，均勻分配到不同的reduce上處理。
案例：
--案例
select
*from a a
join b b
on a.user_id = b.user_id
union
allselect
*from a a
where a.user_id is
null
-- 優化方法：
select
*from a a
left
outer
join b b
oncase
when a.user_id is
null concat(
'dp_hive'
,rand())
else a.user_id end
= b.user_id
（1）現象舉例：如業務需要加工一張訂單商品表，訂單表order和商品表item通過item_id相關聯，每天「熱銷的商品」是固定的幾個item，在未改造前經常出現資料傾斜（這個幾個熱銷的item_id在對應的reduce上處理時間過長）。
（2）解決思路：先生成一張每天的熱銷商品清單表（table_item_top）,然後選取top前4的item_id(根據實際情況而定)，在關聯時，若order的item_id是top前4的item_id，則將item_id轉換為item_id_rand的形式，rand的隨機取值可能時1~n，隨機份數視情況而定；且商品表通過列轉行方式，將商品表中的item_id也生成對應的若干行item_id_rand格式資料，然後兩表通過item_id_rand關聯，熱銷商品將會隨機分配若干份到reduce上並行處理，從而解決傾斜問題。
（3）案例
-- 案例
select t1.order_id,t2.item_name,t2.price
from
(select order_id,item_id from
order
where dt =
'20200305'
)t1
left
outer
join
(select item_id ,item_name,price from item where dt =
'20200305'
)t2
on t1.item_id = t2.item_id;
select t1.order_id, t3.item_name,t3.classname,t3.price
from
(select order_id ,item_id,getrand(item_id,
'table_item_top'
,'rand'
)as item_id_rand
from
order
where dt =
'20200305'
)t1left
outer
join
(select col1 as item_id_rand,itemname,classname,price from
(select item_id,getrand(item_id,
'table_item_top'
,'read'
)as item_id_rand,itemname,classname,price from item where dt =
'20200305'
)t2lateral view explode(split(item_id_rand,
',')
)mytable as col1
)t3 on t1.item_id_rand = t3.item_id_rand
（1）現象：一張日誌表，每個商品一條記錄，要和商品關聯。但關聯卻碰到傾斜的問題。日誌表中歐字串id，也有數字的商品id，字段型別是string，但商品中的數字id是bigint的。猜測問題的原因是吧s8的商品id轉換成數字id做hash來分配reduce，所以字串id的s8日誌，都到乙個reduce上了。
（2）優化方法：把資料型別轉換成字串型別
select
*from s8_log a
left
outer joun r_auction b
on a.auction_id = cast(b.auction_id as string)
高效能mysql學習筆記
此文已由作者朱笑天授權網易雲社群發布。筆者在工作之餘閱讀了一下高效能mysql，以下的內容對mysql的介紹以及書中涉及一些概念的總結歸納。1.mysql架構 1.最上層負責鏈結處理 認證授權 安全等 2.中間一層涵蓋了mysql的大多數核心功能。包括查詢解析 分析 優化 快取 內建函式 所有的誇儲...
mysql高效能學習（一）
最上層的服務不是，mysql所獨有的，主要用於連線處理，授權認證，安全等。第二層是mysql的核心層，所有核心功能都在這一層，包括查詢解析，分析，優化，快取 以及所有的內建函式，所有跨儲存引擎功能 都在這 一層實現 儲存過程，觸發器，檢視等。第三層包含了儲存引擎，負責mysql中資料的儲存和提取。1...
高效能MySQL學習筆記一 MySQL架構
mysql最與眾不同的特性是 它的儲存引擎架構，這種架構的設計將查詢處理以及其他系統任務和資料的儲存 提取相分離。這種處理和儲存相分離的設計可以在使用時根據效能 特性，以及其他需求來選擇資料儲存的方式。mysql預設採用自動提交模式。設定是否自動提交 1為自動提交，0禁用，禁用後，使用commit或...