SQL：表关联与子查询

1、(INNER) JOIN ：

　　内链接，也就是交集。

　　这种拼接得到最少的数据量，效率较高，但在数据分析中使用频率非常低，原因是这种拼接不分主次表，在完成表拼接的同时也做了条件筛选。

　　而表拼接是比较初始的数据整理，过早排除一些数据是不明智的，往往不到最后的数据聚合无法确认哪些数据是否是必须的，

　　此时再返回更改拼接逻辑，往往会导致后续的整个整合过程中出现聚合或筛选逻辑误差，从而花费大量的精力排错。 

2、LEFT JOIN  ：

　　左（外）连接，即左为主表，是最常用的拼接，逻辑是把右侧表中能与左侧表关联上的记录拼接在左侧表后面（默认排列，也可以根据需要重新排列字段顺序），

　　如果右侧表有m条记录可以与左侧n条记录相关联，则左侧主表将生成n*m条记录，可以根据on 关联条件或where筛选条件排除不需要的数据。

3、RIGHT JOIN  ：右（外）连接与LEFT JOIN 其实等价，一般习惯为左边主表，所以right join 不常用。

4、FULL (OUTER) JOIN ：

　　全拼接 ，即保留左右未匹配上的数据，一般用于主键或联合主键等价的多数据源的整合拼接，如 表_A 包含用户的a、b类信息，表_B 包含用户的c、d类信息，

　　但两个表包含的用户量并不一定相同，即可能是两个表包含的用户量簿相同，也可能是 部分表_A 的用户没有c、d信息，或部分部分 表_B 用户没有a、b信息。

　　而我们又需要得到一张横向展开a、b、c、d字段的宽表以便于进一步的聚会统计分析，这种情形，无论是left join 还是right join 都无法得到完整的数据，此时就需要用到全拼接。

　　hive_SQL 语法：

　　SELECT NVL(a.a,'')  a,NVL(a.b,'') b,NVL(b.c,'') c,NVL(b.d,'') d　

　　　　FROM table_A a full join table_B b

　　　　ON a.user_id = b.user_id 

　　MySQL好像没有全拼接吧，需要用union 方式转换一下，貌似。。。

5、ON 拼接条件,MySQL 允许非等值（>,<...）拼接，hive 只支持等值链接 即 (=)

6、CROSS JOIN  或 ","：

　　SELECT  * FROM tb_A,tb_B ，

　　SELECT * FROM table_A,table_B

　　这种拼接方法为笛卡儿积，得到所有可能的连接结果，此拼接不需要on 拼接条件，

　　在一些特殊的情况下，尤其是时间纵向的数据分析有奇效，这种拼接导致数据量指数膨胀，易造成数据倾斜，运算阻塞奔溃，要慎用。。。

　　WHERE 筛选条件

7、union all ：上下拼接（并集），不去重

　　union ：上下拼接，去重，且按默认方式排序

8、子查询：

　　即把其中一个select的结果作为另一个select 的where 筛选条件

　　SELECT* FROM table_A  a 

　　　　WHERE a.id IN (SELECT id FROM table_B WHERE id>n)

　　实际应用过程中，子查询情况并不多，运行效率不高，且容易导致脚本复杂，可读性太差，尤其时在复杂的SQL脚本中，实用性不高，可以通过常规拼接代替。