公司实用Hadoop构建数据仓库，期间不可避免的实用HiveSql，在Etl过程中，速度成了避无可避的问题。本人有过几个数据表关联跑1个小时的经历，你可能觉得无所谓，可是多次Etl就要多个小时，非常浪费时间，所以HiveSql优化不可避免。

注：本文只是从sql层面介绍一下日常需要注意的点，不涉及Hadoop、MapReduce等层面，关于Hive的编译过程，请参考文章：http://tech.meituan.com/hive-sql-to-mapreduce.html

二、准备数据

假设咱们有两张数据表。

景区表：sight，12W条记录，数据表结构：

hive> desc sight;
OK
area                    string                  None                
city                    string                  None                
country                 string                  None                
county                  string                  None                
id                      string                  None                
name                    string                  None                
region                  string                  None     

景区订单明细表：order_sight，1040W条记录，数据表结构：

hive> desc order_sight;    
OK
create_time             string                  None                
id                      string                  None                
order_id                string                  None                
sight_id                bigint                  None  

 三、分析

3.1 where条件

那么咱们希望看见景区id是9718，日期是2015-10-10的所有订单id，那么sql需要如下书写：

select s.id,o.order_id from sight s left join order_sight o on o.sight_id=s.id where s.id=9718 and o.create_time = ‘2015-10-10‘; 

需要的时间是52秒，如果咱们换一个sql的书写方式：

select s.id,o.order_id from sight s left join (select order_id,sight_id from order_sight where create_time = ‘2015-10-10‘) o on o.sight_id=s.id where s.id=9718；

实用43秒，快了一些。当然咱们并不是仅仅分析说快了20%（我还多次测试，这次的差距最小），而是分析原因！

单从两个sql的写法上看的出来，特别是第二条的红色部分，我将left的条件写到里面了。那么执行的结果随之不一样，第二条的Reduce时间明显小于第一条的Reduce时间。

原因是这两个sql都分解成8个Map任务和1个Reduce任务，如果left的条件写在后面，那么这些关联操作会放在Reduce阶段，1个Reduce操作的时间必然大于8个Map的执行时间，造成执行时间超长。

结论：当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤