需要滿足以下條件：
hive.mapred.mode=true，嚴格模式不允許執行以下查詢：
分區表上沒有指定了分區
沒有limit限制的order by語句
笛卡爾積：JOIN時沒有ON語句
兩個聚集函數不能有不同的DISTINCT列，以下表達式是錯誤的：
SELECT語句中只能有GROUP BY的列或者聚集函數。
第壹個MRJob 中，
Map的輸出結果集合會隨機分布到Reduce中，每個Reduce做部分聚合操作，並輸出結果，這樣處理的結果是相同的GroupBy Key
有可能被分發到不同的Reduce中，從而達到負載均衡的目的；第二個MRJob再根據預處理的數據結果按照GroupBy Key分布到
Reduce中（這個過程可以保證相同的GroupBy Key被分布到同壹個Reduce中），最後完成最終的聚合操作。
FROM test
INSERT OVERWRITE TABLE count1
SELECT count(DISTINCT test.dqcode)
GROUP BY test.zipcode
INSERT OVERWRITE TABLE count2
SELECT count(DISTINCT test.dqcode)
GROUP BY test.sfcode;
ORDER BY colName ASC/DESC
hive.mapred.mode=strict時需要跟limit子句
hive.mapred.mode=nonstrict時使用單個reduce完成排序
SORT BY colName ASC/DESC ：每個reduce內排序
DISTRIBUTE BY(子查詢情況下使用 )：控制特定行應該到哪個reducer，並不保證reduce內數據的順序
CLUSTER BY ：當SORT BY 、DISTRIBUTE BY使用相同的列時。
增加map數目：
當input的文件都很大，任務邏輯復雜，map執行非常慢的時候，可以考慮增加Map數，來使得每個map處理的數據量減少，從而提高任務的執行效率。
假設有這樣壹個任務：
select data_desc, count(1), count(distinct id),sum(case when …),sum(case when ...),sum(…) from a group by data_desc
如果表a只有壹個文件，大小為120M，但包含幾千萬的記錄，如果用1個map去完成這個任務，肯定是比較耗時的，這種情況下，我們要考慮將這壹個文件合理的拆分成多個，這樣就可以用多個map任務去完成。
set mapred.reduce.tasks=10;
create table a_1 as select * from a distribute by rand(123);
這樣會將a表的記錄，隨機的分散到包含10個文件的a_1表中，再用a_1代替上面sql中的a表，則會用10個map任務去完成。每個map任務處理大於12M（幾百萬記錄）的數據，效率肯定會好很多。
reduce數目設置：
參數1：hive.exec.reducers.bytes.per.reducer=1G：每個reduce任務處理的數據量
參數2：hive.exec.reducers.max=999(0.95 TaskTracker數)：每個任務最大的reduce數目
reducer數=min(參數2,總輸入數據量/參數1)
set mapred.reduce.tasks：每個任務默認的reduce數目。典型為0.99 reduce槽數，hive將其設置為-1，自動確定reduce數目。
15.使用索引：
hive.optimize.index.filter：自動使用索引
hive.optimize.index.groupby：使用聚合索引優化GROUP BY操作