执行顺序
ON 定义表连接字段（数据量大的时候添加索引也可以查询速度进行优化
On.. And.. : And 限定的条件是在 Join之前对目标表的数据进行限定
SELECT * FROM EMPLOY E LEFT JOIN DEPARTMENT D
ON E.DEPTNO=D.DEPTNO AND D.DEPTNO=40
-- EMPLOY 表不添加限制，所有连接之前获取所有EMPLOY表的数据 相当于Select * From Employ tmp_Employ
-- DEPARTMENT 表 ，获取DEPTNO 为40的 数据，Select * from Department where Deptno = 40 tmp_Department
-- 最后结果为 tmp_Department td * tmp_Employ te on te.deptno = td.deptno
SELECT * FROM EMPLOY E LEFT JOIN DEPARTMENT D
ON E.DEPTNO=D.DEPTNO Where D.DEPTNO=40
-- 将 And 换成Where 则变成了两个全表数据关联之后
-- 再对数据进行筛选 Where Deptno = 40 的数据
MSSQL : 执行顺序 From -> Join -> On -> And ->Left(Right) -> Where -> Select
Join的逻辑层
详情博文 ： SQL SERVER – Better Performance – LEFT JOIN or NOT IN?.
个人认为 Outer Join 实际上 是在 Inner join 的结果后再对目标集进行筛选
Join 的物理层
在写查询语句的时候遇到一种情况，两张表关联的时候，对其中的一张小表加上Where条件反而导致了查询速度更慢的问题，最后排查到是优化器，选择了错误的表数据的关联方式
没加Where之前
加了Where之后
初看感觉所有的消耗都在对表查询，实际而次情况的Neseted Loop（嵌套循环） 是性能消耗最高的地方；
Hash Map
Nested Map
Merge Map
底层太难了，懒得写，引用下别人的解释
A nested loop query plan is usually optimal when there are small numbers of rows in one table (think 10s to perhaps 100s in most cases) that can be probed into another table that is either very small or has an index that allows a seek for each input. One thing to watch out for here is when the optimizer THINKS there will be few rows (check the estimated rows in the popup for the estimated query plan graphic) but in reality there are LOTS of rows (thousands or even millions). This is one of the worst things that can happen to a query plan and is usually the result of either out-of-date statistics, a cached query plan or data that is unevenly distributed. Each of these can be addressed to minimize the likelyhood of the problem
.A hash-match plan is optimal when there is a relatively few rows joined into a relatively large number of rows. Gail's post explains the basics of the mechanism. It can get REALLY slow on machines with insufficient buffer RAM to contain the hash tables in memory because they will have to be laid down to disk at a HUGE relative cost.