[TOC] # 注意 1. **order by 會對輸入做全局排序，因此只有一個reducer，會導致當輸入規模較大時，需要較長的計算時間** 2. **sort by不是全局排序，其在數據進入reducer前完成排序。因此，如果用sort by進行排序，并且設置`mapred.reduce.tasks>1`，則sort by只保證每個reducer的輸出有序，不保證全局有序** 3. distribute by(字段) (分發)根據指定的字段將數據分到不同的reducer，且分發算法是hash散列。 4. Cluster by(字段) (桶) 除了具有Distribute by的功能外，還會對該字段進行排序,cluster 和 sort 不能共存 因此，如果分桶和sort字段是同一個時，此時，`cluster by = distribute by + sort by` 分桶表的作用：最大的作用是用來提高join操作的效率； （思考這個問題： `select a.id,a.name,b.addr from a join b on a.id = b.id;` 如果a表和b表已經是分桶表，而且分桶的字段是id字段 做這個join操作時，還需要全表做笛卡爾積嗎？） 5. **對于分區表,除非where語句中含有分區字段過濾條件來限制范圍,否則不允許執行**.換句話說,就是用戶不允許掃描所有分區.進行這個限制的原因是,通常分區表都擁有非常大的數據集,沒有分區限制會消耗巨大資源 6. **對于使用了order by的語句,要求必須使用limit.**因為order by為了執行排序會把所有結果發到一個reducer中進行處理,強制加limit來避免reducer執行過長 7. **限制笛卡爾積的查詢.** # 嚴格模式 **注意：在hive中提供了一種“嚴格模式”的設置來阻止用戶執行可能會帶來未知不好影響的查詢** 設置屬性hive.mapred.mode 為strict能夠阻止以下三種類型的查詢： 1. 除非在where語段中包含了分區過濾，否則不能查詢分區了的表。這是因為分區表通常保存的數據量都比較大，沒有限定分區查詢會掃描所有分區，耗費很多資源。 不允許：`select * from logs;` 允許：`select * from logs where day=20151212;` 2. 包含order by，但沒有limit子句的查詢。因為order by 會將所有的結果發送給單個reducer來執行排序，這樣的排序很耗時 3. 笛卡爾乘積；簡單理解就是JOIN沒帶ON，而是帶where的