full join用于横向拼接两表并保留所有记录（匹配连上、不匹配补null），适用于数据比对等需关联分析场景；union all用于纵向堆叠结构一致的结果集，适用于日志汇总等无需关联的合并场景。
FULL JOIN 和 UNION 解决的是完全不同的问题，不能互换，选错会导致结果错得离谱。
什么时候该用 FULL JOIN？
当你需要把两个表按某个关联字段「横向拼接」，同时保留双方所有记录（匹配的连上，不匹配的补 NULL）时才用它。
典型场景：比对员工主数据和薪资表，查出哪些人有档案但没发薪、哪些有发薪记录但没主数据。
- 必须有明确的连接条件，比如
ON a.id = b.emp_id - 左右表字段不要求一致，结果列是两表字段并集（可能重名需别名处理）
- 如果连接字段无索引，大数据量下性能明显下降，执行计划常出现
HASH JOIN或全表扫描 - MySQL 不支持
FULL JOIN语法，得用LEFT JOIN+RIGHT JOIN+UNION ALL模拟
什么时候该用 UNION 或 UNION ALL？
当你想把两个查询结果「纵向堆叠」成一个结果集，且结构（列数、类型、顺序）完全相同时才适用。
典型场景：合并不同月份的销售流水、汇总多个分库的用户注册日志。
-
UNION会去重，隐式加DISTINCT，多一次排序+去重开销 -
UNION ALL只是物理拼接，零判断，快得多——90% 的日志/报表合并应优先选它 - 列名以第一个
SELECT为准，后续语句列名会被忽略 - Hive、Spark SQL 要求
UNION ALL必须包裹在子查询里，否则报错：FAILED: ParseException line x:x mismatched input 'union' expecting EOF
FULL JOIN 结果错成 UNION 的常见表现
最典型的错误是：本想对比 A 表和 B 表的差异（谁多谁少），却写了 UNION ALL，结果只看到一堆名字堆在一起，完全看不出哪边缺失。
- 误用
UNION合并users和orders表 → 报错：ERROR 1222 (21S01): The used SELECT statements have a different number of columns - 用
FULL JOIN去合并两个结构不同但业务含义相近的日志表（如login_log和pay_log）→ 结果大量NULL，字段语义混乱，根本没法分析 - 在 MySQL 里直接写
FULL JOIN→ 报错：ERROR 1064 (42000): You have an error in your SQL syntax
怎么快速判断该用哪个？
看你要的行是「变宽」还是「变长」：
- 想让一行里同时出现「用户姓名」和「对应订单号」→ 变宽 → 用
JOIN类（含FULL JOIN） - 想让结果里多出几行「来自表A的记录」和「来自表B的记录」→ 变长 → 用
UNION ALL - 不确定字段是否严格一致？先跑
SELECT * FROM table_a LIMIT 1和SELECT * FROM table_b LIMIT 1对比列名与类型
实际写法里最容易被忽略的是：JOIN 关注「关系」，UNION 关注「结构」；关系错了结果逻辑崩，结构错了直接报错或静默截断。
