full outer join可一次性检测双向关联缺失，如数据迁移校验中同时发现“有客户无订单”和“有订单无客户”，mysql需用left+right join加union all模拟，注意where过滤、字段对齐及避免去重。
需要双向缺失检测的场景：比如核对客户表和订单表的“幽灵记录”
当你必须同时确认两边有没有“漏掉的关联”，而不是只关心某一边，FULL OUTER JOIN 就不可替代。典型例子是数据迁移后做一致性校验：把旧系统导出的 customers 表和新系统生成的 orders 表比对，既要找出“有客户但没订单”（可能是导入失败），也要找出“有订单但没客户”（可能是脏数据或匿名下单）。用 LEFT JOIN 或 RIGHT JOIN 都只能看到单边缺失，必须两次查询再人工合并——而 FULL OUTER JOIN 一次查清。
跨源数据整合时保留全部原始实体：比如合并两个独立运营的销售团队数据
两个团队各自维护自己的 products 表，字段基本一致但主键不统一、部分产品重名但 ID 不同、还有各自独有的 SKU。你想生成一份“全量产品清单”，既不能丢掉任一团队的产品，也不能强行去重覆盖原始归属。这时 FULL OUTER JOIN 搭配 COALESCE(product_id_a, product_id_b) 和显式标记来源字段，比先 UNION ALL 再去重更可控——因为你能明确知道哪一行来自哪张表，哪些字段因无匹配而为 NULL，后续清洗逻辑更清晰。
MySQL 8.0 以下版本必须手动模拟 FULL OUTER JOIN
MySQL 直到 8.0 才原生支持 FULL OUTER JOIN，老版本得靠 (SELECT ... FROM a LEFT JOIN b ...) UNION ALL (SELECT ... FROM a RIGHT JOIN b ... WHERE a.id IS NULL)。注意三点：
- 必须用
UNION ALL而不是UNION，否则重复的匹配行会被去重，导致结果少行 -
RIGHT JOIN子句里要加WHERE a.id IS NULL过滤掉已出现在左连接里的行，否则会重复 - 两个子查询的列顺序、类型、别名必须完全一致，否则
UNION会报错
性能和可读性容易被低估的关键点
FULL OUTER JOIN 在大数据量下比 INNER JOIN 或 LEFT JOIN 更耗资源，因为它要扫描并保留两边所有行。最容易被忽略的是：即使你只关心其中一边的 NULL 值（比如只找“无客户订单”），数据库仍得构造完整结果集再过滤——所以如果业务逻辑本身只依赖单边缺失，优先考虑拆成两个 LEFT JOIN 查询 + 应用层合并，反而更快更省内存。另外，结果中大量 NULL 值会让 GROUP BY 或聚合函数行为变复杂，比如 COUNT(*) 包含所有行，但 COUNT(col) 会跳过 NULL，这点在写报表逻辑时极易出错。
