FULL OUTER JOIN易慢因其需保留两表全部行并补NULL，无法剪枝，常退化为双表全扫描+合并去重，导致高逻辑读、大内存占用及磁盘溢出；分区交换无效，真正优化应重写为UNION去重键后双LEFT JOIN并加索引。
完全外连接（FULL OUTER JOIN）为什么容易慢
因为 FULL OUTER JOIN 本质上要保留左表和右表的所有行，对不匹配的行补 NULL，数据库无法像 INNER JOIN 那样剪枝，也无法像 LEFT JOIN 那样只驱动一侧。多数引擎会退化为两路独立扫描 + 合并去重（或哈希全集），导致逻辑读高、内存占用大、易触发 Spill to TempDB 或磁盘排序。
分区交换（Partition Switching）在 FULL OUTER JOIN 中基本无效
分区交换是 DDL 操作，用于快速替换整个分区（如按月切换历史表），它不参与查询执行计划生成，也不能加速 FULL OUTER JOIN 的运行时匹配逻辑。试图用 SWITCH PARTITION 优化 FULL OUTER JOIN 属于典型误用——该操作不改变连接算法，也不减少扫描行数。
- 分区交换只适用于目标表结构完全一致、且分区键与连接键无关的场景
-
FULL OUTER JOIN的性能瓶颈在匹配阶段，不是数据加载阶段 - 若强行将左右表按相同分区键切分后分别
LEFT JOIN+RIGHT JOIN再UNION ALL，反而引入重复计算和去重开销
并行扫描能起作用，但有严格前提
并行扫描本身不是 FULL OUTER JOIN 的专属优化手段，它的效果取决于执行引擎是否选择并行 Hash Join 或并行 Merge Join，而这又依赖于：表是否足够大、统计信息是否准确、cost threshold for parallelism 设置是否合理、以及左右表连接键上是否有可用索引。
- SQL Server 中，若左右表都大于约 50 万行且连接列有索引，优化器更倾向生成并行 Hash Join；MySQL 8.0+ 和 PostgreSQL 13+ 也支持并行顺序扫描，但仅当
FULL OUTER JOIN被重写为LEFT JOIN+RIGHT JOIN+UNION ALL时才可能触发 - 并行不会降低总工作量，只是把扫描/哈希构建/探测任务分发到多个线程——若 IO 或内存带宽已达瓶颈，并行反而增加调度开销
- 务必检查执行计划中是否出现
Gather（PostgreSQL）、Parallelism（SQL Server）或Worker（MySQL）算子，没有就说明没真正并行
真正有效的替代方案：重写 + 索引 + 数据裁剪
与其强求优化 FULL OUTER JOIN 本身，不如判断业务是否真的需要“完全外连接”。90% 的所谓 FULL OUTER JOIN 场景，实际只需要“所有主键存在记录的并集”，这时可安全改写为：
SELECT id, COALESCE(t1.val, t2.val) AS val FROM (SELECT id FROM t1 UNION SELECT id FROM t2) keys LEFT JOIN t1 ON keys.id = t1.id LEFT JOIN t2 ON keys.id = t2.id;
这个写法的优势：
- 避免双侧全扫描，先用
UNION提取唯一键（可走索引） - 两次
LEFT JOIN均可利用id上的索引实现Index Seek - 如果业务允许延迟几秒，还可对
t1和t2按时间范围预过滤（如加WHERE dt >= '2026-04-01'），大幅减少输入行数
最后提醒：FULL OUTER JOIN 在 OLAP 场景下常被滥用。如果表来自不同系统、schema 不一致、或存在大量 NULL 键值，先清洗数据比调优 SQL 更有效——索引救不了语义混乱的连接。
