mysql不支持full outer join，需用left join+right join+union all组合实现：先取左表全量及匹配右表数据，再补右表独有行（where左表id is null），必须用union all避免去重误删，且字段名、类型、顺序须严格对齐。
MySQL 不支持 FULL OUTER JOIN，直接写会报错 ERROR 1064；PostgreSQL、SQL Server、Oracle 可以原生使用，但 NULL 处理和连接键质量直接影响结果可信度。
MySQL 怎么写等效的 Full Outer Join
必须用 LEFT JOIN + RIGHT JOIN + UNION ALL 拼接，且两个子查询都要加 WHERE 过滤条件，否则交集行重复、NULL 键漏匹配。
-
LEFT JOIN部分保留左表全部，右表不匹配字段为NULL -
RIGHT JOIN部分只取“右表有、左表无”的行，必须加WHERE left_table.id IS NULL - 必须用
UNION ALL，不是UNION——后者会去重，但两部分的 NULL 行结构相同，会被误删 - 列名要显式列出，不能用
*，否则字段顺序或别名冲突会导致UNION失败
示例（合并用户表 users 和订单表 orders）：
codex-orchestration
下载
一款AI工具，主要用于Codex 通用编排：利用 `update_plan` 与后台 PTY 终端并行运行 `codex exec` 工作进程，适合需要提升相关任务效率的用户。
SELECT u.id, u.name, o.order_id, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id UNION ALL SELECT u.id, u.name, o.order_id, o.amount FROM users u RIGHT JOIN orders o ON u.id = o.user_id WHERE u.id IS NULL;
PostgreSQL 中 FULL OUTER JOIN 的 NULL 陷阱
语法没问题，但结果里大量 NULL 容易在后续过滤或聚合中“静默丢数据”。比如加了 WHERE amount > 100，所有右表独有行（amount 是 NULL）全被干掉，实际本意可能是“金额超 100 或该用户根本没下单”。
-
WHERE条件里涉及任一表的字段，都要考虑IS NULL分支 - 连接键本身允许
NULL？那FULL OUTER JOIN会产生笛卡尔爆炸——两表各 3 条id IS NULL记录，会产出 9 行 - 安全做法是在
ON子句里排除：ON u.id = o.user_id AND u.id IS NOT NULL AND o.user_id IS NOT NULL - 主键字段一般不会为
NULL，但业务字段（如region_code）常有空值，得提前清洗或用COALESCE归一化
跨系统基础数据合并时最关键的三件事
不是语法对了就行。两个系统原始数据结构不同、主键定义不一致、空值含义不统一，直接连会出脏数据。
- 先确认“匹配依据”是否真能唯一对应：比如系统 A 用手机号，系统 B 用邮箱，中间没做映射就硬连，结果全是
NULL - 字段类型要对齐：
INT和VARCHAR连不上；时间字段一个存 UTC 一个存本地时区，JOIN条件失效 - 业务上“空”不等于“不存在”：系统 A 的
status = NULL表示待审核，系统 B 的status = NULL表示已注销——合并后不能简单填COALESCE(a.status, b.status)
真正难的从来不是写对那一行 FULL OUTER JOIN，而是搞清两边字段背后的真实业务语义。空值怎么解释，缺失代表什么，要不要补默认值——这些不厘清，SQL 写得再漂亮，结果也是误导。
