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脚本中，实用性不高，可以通过常规拼接代替。
标签：JOIN,join,查询,拼接,SQL,与子,table,id,SELECT From： https://www.cnblogs.com/bigcat-sniffs-the-rose/p/16777943.html