⑴ sql 之 ON 和 WHERE执行顺序
那么 WHERE 是不是一定是在 ON 之后生效了 ？ 我们带着这个疑问往下看
on 针对的关联条件，是表与表之间通过哪些列、以什么条件进行关联，而 where 针对的是过滤条件；两者从概念上来讲是不同的
另外 on 一定是与 join 一并使用的，join 会添加外部行，并将外部行中被驱动表的字段填充 null ，而 where 进行过滤的时候，只有逻辑判断为 true 的记录才会保留，逻辑值为 false 和 unknown 的记录都会过滤掉；两者得到的结果会有所不同。
上面说的可能有些抽象，我们结合具体示例来看；MySQL 版本 5.7.21 ，准备表和初始数据
我们先来看看 left join（right join类似）
我们可以看到：
我们再来看看 inner join
我们可以看到，执行结果是一样的，inner join 查询的就是驱动表与被驱动表同时存在的记录，所以过滤条件不管放在 ON 里，还是放在 WHERE 里，执行结果是一样的
ON 和 WHERE 的生效时机
ON 后的关联条件与 WHERE 后的过滤条件，这两者的执行顺序是否如 SQL 执行顺序图中说的那样，ON 一定先与 WHERE ？
问题先放着，我们以 left join 为例，来看看 4 个案例，也许从中能找到我们想要的答案
1、左表与右表都没二级索引
刚好上面的 tbl_a 和 tbl_b 满足条件，我们来看看 SQL 的执行计划
驱动表是 tbl_a，这个相信大家没问题，我们重点看下 type 和 Extra
这条 SQL 的执行流程应该是这样的：
此时大家看出什么了没 ？ ON 后的关联条件是在 WHERE 后的过滤条件之前生效的吗 ？
这个案例不太常见，因为表没有二级索引，我们接着往下看看有二级索引的情况
2、左表有二级索引，右表无二级索引
我们在 tbl_a 建一个组合索引 create index idx_bcd on tbl_a(b, c, d); ，然后往 tbl_a 和 tbl_b 中各插入 10W 条记录，我们再来看执行计划
此时 WHERE 后的过滤条件的生效时机也是早于 ON 后的关联条件的。
3、左表无二级索引，右表有二级索引
将 tbl_b 作为左表，tbl_a 作为右表，我们来看效果
4、左表与右表都有二级索引
我们在 tbl_b 表上建一个组合索引 create index idx_bcd on tbl_b(b, c, d); 我们来看看 SQL 的执行计划
自此，关于 ON 和 WHERE 的生效时机，你清楚了吗 ？
他两的生效时机，需要结合表结构，以及具体的 SQL 来分析，而不是 ON 一定先于 WHERE
⑵ 大数据开发工程师Hive(Hive Sql的执行顺序)
Hive中SQL的执行顺序：
（1） from ：对from左边的表和右边的表计算笛卡尔积，产生虚表VT1；
（2） on : 对虚表VT1进行on过滤，只有那些符合 的行才会被记录在虚表VT2中；
（3） join ：如果指定了outer join（比如left join、 right join），那么保留表中未匹配的行就会作为外部行添加到虚拟表VT2中，产生虚拟表VT3；
（4） where ：对虚拟表VT3进行where条件过滤。只有符合 的记录才会被插入到虚拟表VT4中；
（5） group by ：根据group by子句中的列，对VT4中的记录进行分组操作，产生VT5；
（6） having ： 对虚拟表VT5应用having过滤，只有符合 的记录才会被 插入到虚拟表VT6中；
（7） select ：执行select操作，选择指定的列，插入到虚拟表VT7中；
（8） distinct ：对VT7中的记录进行去重。产生虚拟表VT8；
（9） order ：将虚拟表VT8中的记录按照 进行排序操作，产生虚拟表VT9；
（10） limit ：取出指定行的记录，产生虚拟表VT10, 并将结果返回；
partition by 通常会用于和开窗及分析函数一起使用，partition by是在select执行完 后 的结果集上进行的；
(每日1小题，进步1点点)
⑶ sql执行顺序以及on和where的区别
（1.)select语句的执行顺序
Processing Order of the SELECT statement
The following steps show the processing order for a SELECT statement.
1.FROM
2.ON
3.JOIN
4.WHERE
5.GROUP BY
6.WITH CUBE or WITH ROLLUP
7.HAVING
8.SELECT
9.DISTINCT
10.ORDER BY
11.TOP
(5)SELECT DISTINCT
（7）TOP(<top_specification>) <select_list>
(1)FROM <left_table> <join_type> JOIN <right_table> ON <on_predicate>
(2)WHERE <where_predicate>
(3)GROUP BY <group_by_specification>
(4)HAVING <having_predicate>
(6)ORDER BY <order_by_list>
T-SQL在查询各个阶级分别干了什么：
（1）FROM 阶段
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）
（2）WHERE阶段
WHERE阶段是根据<where_predicate>中条件对VT1中的行进行筛选，让条件成立的行才会插入到VT2中。
（3）GROUP BY阶段
GROUP阶段按照指定的列名列表，将VT2中的行进行分组，生成VT3。最后每个分组只有一行。
（4）HAVING阶段
该阶段根据HAVING子句中出现的谓词对VT3的分组进行筛选，并将符合条件的组插入到VT4中。
（5）SELECT阶段
这个阶段是投影的过程，处理SELECT子句提到的元素，产生VT5。这个步骤一般按下列顺序进行
a.计算SELECT列表中的表达式，生成VT5-1。
b.若有DISTINCT，则删除VT5-1中的重复行，生成VT5-2
c.若有TOP，则根据ORDER BY子句定义的逻辑顺序，从VT5-2中选择签名指定数量或者百分比的行，生成VT5-3
（6）ORDER BY阶段
根据ORDER BY子句中指定的列明列表，对VT5-3中的行，进行排序，生成游标VC6.
如果On和where只能选其一的话：
先进行on的过滤, 而后才进行join, 这样就避免了两个大表产生全部数据的笛卡尔积的庞大数据.
这些步骤执行时, 每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者（客户端应用程序或者外部查询）不可用。只是最后一步生成的表才会返回 给调用者。
如果没有在查询中指定某一子句，将跳过相应的步骤。
（2） 那 on 和where 那个更高效呢
如果是inner join, 放on和放where产生的结果一样, 但没说哪个效率速度更高? 如果有outer join (left or right), 就有区别了, 因为on生效在先, 已经提前过滤了一部分数据, 而where生效在后.
综合一下, 感觉还是放在on里更有效率, 因为它先于where执行.
先笛卡尔积, 然后再on过滤, 如果join是inner的, 就继续往下走, 如果join 是left join, 就把on过滤掉的左主表中的数据再添加回来; 然后再执行where里的过滤;
on中不是最终过滤, 因为后面left join还可能添加回来, 而where才是最终过滤.
只有当使用外连接(left, right)时, on 和 where 才有这个区别, 如果用inner join, 在哪里制定都一样, 因为on 之后就是where, 中间没有其它步骤.
⑷ 关于SQL中join on 的用法神马的
join on 就是表连接.
select * from table1 as t1 join table2 as t2 on(t1.a= t2.b) where t1.c = x order by t1.d desc;
等价于
select * from table 1 as t1 ,table2 as t2 where t1.a = t2.b and t1.c = x order by t1.d desc;
2个SQL语句对于数据库来说是一样的,执行计划都没有区别...
你可以试一下.