【Hive】语句执行顺序

① FROM阶段标识出查询的来源表，并处理表运算符。在涉及到联接运算的查询中（各种join），主要有以下几个步骤：

• a.求笛卡尔积。不论是什么类型的联接运算，首先都是执行交叉连接（cross join），求笛卡儿积，生成虚拟表VT1-J1。
• b.ON筛选器。这个阶段对上个步骤生成的VT1-J1进行筛选，根据ON子句中出现的谓词进行筛选，让谓词取值为true的行通过了考验，插入到VT1-J2。
• c.添加外部行。如果指定了outer join，还需要将VT1-J2中没有找到匹配的行，作为外部行添加到VT1-J2中，生成VT1-J3。

经过以上步骤，FROM阶段就完成了。概括地讲，FROM阶段就是进行预处理的，根据提供的运算符对语句中提到的各个表进行处理（除了join，还有apply，pivot，unpivot）

② WHERE阶段
WHERE阶段是根据<where_predicate>中条件对VT1中的行进行筛选，让条件成立的行才会插入到VT2中。

③ GROUP BY阶段
GROUP阶段按照指定的列名列表，将VT2中的行进行分组，生成VT3。最后每个分组只有一行。

④ HAVING阶段
该阶段根据HAVING子句中出现的谓词对VT3的分组进行筛选，并将符合条件的组插入到VT4中。

⑤ SELECT阶段
这个阶段是投影的过程，处理SELECT子句提到的元素，产生VT5。这个步骤一般按下列顺序进行

• a.计算SELECT列表中的表达式，生成VT5-1。
• b.若有DISTINCT，则删除VT5-1中的重复行，生成VT5-2
• c.若有TOP，则根据ORDER BY子句定义的逻辑顺序，从VT5-2中选择签名指定数量或者百分比的行，生成VT5-3

⑥ ORDER BY阶段
根据ORDER BY子句中指定的列明列表，对VT5-3中的行，进行排序，生成游标VC6.

如果On和where只能选其一的话：
先进行on的过滤, 而后才进行join, 这样就避免了两个大表产生全部数据的笛卡尔积的庞大数据.
这些步骤执行时, 每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者（客户端应用程序或者外部查询）不可用。只是最后一步生成的表才会返回 给调用者。
如果没有在查询中指定某一子句，将跳过相应的步骤。

那 on 和where 那个更高效呢？
如果是inner join, 放on和放where产生的结果一样, 但没说哪个效率速度更高? 如果有outer join (left or right), 就有区别了, 因为on生效在先, 已经提前过滤了一部分数据, 而where生效在后.

1、对于 Left outer Join ，右侧的表写在 on后面、左侧的表写在 where后面，性能上有提高；（因为左表是全部保留的）

2、对于 Right outer Join，左侧的表写在 on后面、右侧的表写在 where后面，性能上有提高；

3、对于inner join，都可以

综合一下, 感觉还是放在on里更有效率, 因为它先于where执行.
先笛卡尔积, 然后再on过滤, 如果join是inner的, 就继续往下走, 如果join 是left join, 就把on过滤掉的左主表中的数据再添加回来; 然后再执行where里的过滤;
on中不是最终过滤, 因为后面left join还可能添加回来, 而where才是最终过滤.
只有当使用外连接(left, right)时, on 和 where 才有这个区别, 如果用inner join, 在哪里制定都一样, 因为on 之后就是where, 中间没有其它步骤.

另外注意：
左连接保证左边的数据都存在，不管右表是否有数据，左边数据均会被查出。当左表的一条数据右表有一条或多条匹配时，每一条都会被重复查出，导致最后数据比原左表多。解决方法是：添加group by 字段，就可以保证该字段具有唯一性。