UNION ALL 是纯拼接，FULL JOIN 是分布式匹配：前者按顺序追加结果、不排序不比较；后者需重分区、同键匹配、补NULL、维护存在性标记，开销大且易倾斜。
UNION ALL 是纯拼接，FULL JOIN 是分布式匹配
UNION ALL 的执行路径极简：数据库引擎按顺序执行每个 SELECT，把结果集逐行输出、直接追加，不建临时表、不排序、不哈希、不比较。而 FULL JOIN（尤其在 Hive 或大数据引擎中）必须先按连接键重分区，再把左右表同键数据拉到同一 Reduce 或 Task 中做笛卡尔积式匹配——哪怕只有一行重复键，也可能触发单点倾斜和磁盘落写。
FULL JOIN 的 NULL 处理开销被严重低估
FULL JOIN 必须确保左表缺失右表匹配时补 NULL、右表缺失左表匹配时也补 NULL，这要求引擎全程维护两套存在性标记，并在最终合并阶段做逻辑判断与字段对齐。UNION ALL 完全不关心关联关系，NULL 就是普通值，照搬输出。常见翻车点：SELECT id, name FROM t1 和 SELECT id, NULL AS name FROM t2 用 UNION ALL 没问题；但若用 FULL JOIN，name 类型不一致或隐式转换失败，会直接报错或返回意外截断值。
列对齐方式根本不同，导致优化器失效场景更多
UNION ALL 只校验列数与类型兼容性，且以第一个 SELECT 的列名为准；FULL JOIN 要求显式指定每张表的字段别名、处理同名列冲突、支持 USING 或 ON 多条件，优化器需推导连接谓词、估算基数、选择驱动表——这些步骤在数据量大或统计信息不准时极易选错执行计划。实测 MySQL 8.0 下，100 万行 × 10 万行 FULL JOIN 耗时常超 15 秒，而同等数据用 UNION ALL 拼接仅 800ms 左右。
你真正需要的是“合并”还是“关联”？
如果业务语义只是把 A 表和 B 表的数据“堆在一起”（比如日志分表、多租户数据归档、ETL 中间层汇总），那用 FULL JOIN 属于误用：它强行建立行级映射，却从不使用映射结果。此时 UNION ALL 不仅快，逻辑也干净。容易被忽略的关键点：FULL JOIN 的结果行数可能远超两个输入表之和（因一对多匹配爆炸），而 UNION ALL 的行数永远等于各子查询行数之和——这个确定性本身就是性能可控的前提。
