Oracle Full Join为何无重复行：理论认知与实际执行的差异

你遇到的认知矛盾，本质是混淆了不支持原生Full Join的数据库上，手写模拟Full Join的写法特性和支持原生Full Join的数据库引擎的内部实现逻辑，两者从设计上就不存在必然的行为一致性。

为什么教程会提到Full Join模拟时会保留重复行？ #

• 这类教程一般针对没有原生FULL OUTER JOIN支持的数据库场景，比如早期MySQL版本。因为没有内置语法，社区通用的模拟思路是把左连接、右连接的结果做合并。
• 如果直接用UNION ALL拼接两个连接的结果，会天然保留重复行：左连接的结果里包含两部分——满足连接条件的匹配公共行、左表独有的右表为NULL的行；右连接的结果里同样包含两部分——和左连接完全一致的匹配公共行、右表独有的左表为NULL的行。两者直接拼接，那批公共行就会被重复输出。这也是教程特意提醒“模拟场景下要注意UNION和UNION ALL的选择”的原因——如果不想要重复行，才需要换成带自动去重的UNION。
• 教程里描述的「保留重复行」，是针对这种纯手写拼接的模拟方式的输出特性，不是SQL标准里定义的原生Full Join的标准行为。

为什么Oracle执行原生Full Join时看不到重复行？ #

• 你实际在Oracle中执行的三个查询（左连接、右连接、原生全连接）的结果观察是完全准确的：原生Full Join的输出，既包含左表独有、右表为NULL的行，也包含右表独有、左表为NULL的行，同时匹配上的公共行只会返回一次，完全没有重复。
• 这是因为数据库引擎对FULL OUTER JOIN的实现是内置优化的原生逻辑，并不会真的像手写模拟那样，先跑完整个左连接、再跑完整个右连接，最后把两个结果集拼起来。它的实际执行逻辑是：
  1. 按连接键对左右两表做关联匹配，所有满足匹配条件的公共行只返回一次；
  2. 追加返回左表中不存在匹配右表记录的行，右表对应字段自动补NULL；
  3. 追加返回右表中不存在匹配左表记录的行，左表对应字段自动补NULL。
• 整个流程从设计源头就避免了公共行的重复返回，自然不需要对结果做二次去重，也就不会出现手写拼接带来的重复行问题。

关于你之前的推测的偏差 #

你之前推测“Oracle内部是通过对左右连接的结果执行UNION ALL操作来实现Full Join”，这个判断和实际输出结果是矛盾的：

• 如果真的直接对左右连接的完整结果做UNION ALL，那么所有匹配上的公共行必然会在结果集里出现两次，和你实际查询到的无重复结果完全不符。
• 原生Full Join的实现从根本上绕过了“左右连接重复返回公共行”的问题，不需要经过完整的左右连接执行、再做UNION的流程。

补充常见的认知误区 #

如果哪天你在支持原生Full Join的数据库上，看到结果里出现了重复行，基本和手写模拟的重复不是一回事：这种场景下的重复，一般是因为连接键存在一对多的匹配关系——比如某条客户记录关联了多条订单记录，本身就需要返回多行结果，和左右连接拼接带来的公共行重复没有关系。

内容的提问来源于stack exchange，提问作者AnonymousMe