MySQL不支持FULL JOIN，需用LEFT JOIN与RIGHT JOIN结合UNION ALL模拟；PostgreSQL和SQL Server虽支持但需注意NULL值在ON条件中不匹配的问题。
MySQL不支持FULL JOIN，得用LEFT JOIN + RIGHT JOIN模拟
MySQL从8.0开始仍不原生支持FULL JOIN，直接写会报错ERROR 1064。想拿到两表所有记录，必须手动拼接：先用LEFT JOIN取左表全量+右表匹配部分，再用RIGHT JOIN取右表中没被左表覆盖的记录，最后UNION ALL合并。
注意UNION ALL比UNION快，因为不查重；但前提是确保两部分结果无交集（即右表独有部分确实没在左连接结果里出现），否则会重复。
- 左连接部分要包含右表字段，用
NULL占位未匹配行 - 右连接部分要过滤掉已在左连接中出现的右表记录（通常靠
WHERE left_table.id IS NULL） - 字段顺序、类型、别名必须完全一致，否则
UNION ALL会失败
PostgreSQL和SQL Server可以直接用FULL JOIN，但NULL值处理要小心
PostgreSQL和SQL Server支持标准FULL JOIN语法，写起来简洁：SELECT * FROM a FULL JOIN b ON a.id = b.id。但实际用时容易忽略：连接字段值为NULL时，ON条件永远不成立，这些行不会被关联上——也就是说，FULL JOIN只保证“两表所有行都出现”，不保证“所有NULL值都被关联”。
常见陷阱是拿含NULL的字段做ON条件，比如ON a.code = b.code，而a或b的code列本身有NULL，那这些行就变成各自孤立的NULL行，不是你预期的“配对”。
- 如果业务逻辑需要把
NULL也当作可匹配值，得改用IS NOT DISTINCT FROM（PostgreSQL）或COALESCE(a.code, '') = COALESCE(b.code, '') -
FULL JOIN结果中，来自左表但右表无匹配的行，右表字段全为NULL；反之亦然，别漏判NULL导致后续WHERE过滤出错
用FULL JOIN前先确认是否真需要“全部记录”
多数场景下，所谓“要两表全部数据”，其实真正要的是“左表全量 + 右表补充字段”，也就是LEFT JOIN就够了；或者“以某维度汇总后补全缺失组合”，这时更适合用CROSS JOIN加LEFT JOIN，而不是FULL JOIN。
举个例子：统计每个部门每个季度销售额，但某些部门某季度没数据。此时FULL JOIN部门表和季度表会生成所有组合，再左连销售表，本质是CROSS JOIN + LEFT JOIN，不是纯FULL JOIN能一步解决的。
- 先画出数据关系图：哪张表是主维度？哪张是事实表？
- 检查是否有外键约束或业务规则限制了合法组合，盲目
FULL JOIN可能引入大量无意义的NULL行 - 大数据量时，
FULL JOIN结果集可能远超任一原表，内存和网络传输压力陡增
替代方案：用UNION ALL + 子查询更可控
当FULL JOIN语义模糊或数据库不支持时，显式写出左右独有部分往往更安全。比如：先查左表所有记录并标记来源，再查右表中id不在左表中的记录，同样标记来源，UNION ALL后统一处理。
这样做的好处是逻辑清晰、每部分可单独测试、能加索引优化、且避免FULL JOIN在复杂ON条件下产生的意外行为。
- 子查询里记得给
SELECT列起一致别名，尤其涉及计算字段时 - 用
NOT EXISTS比NOT IN更可靠，避免右表id含NULL导致整个子查询返回空 - 如果两表都有大量重复
id，FULL JOIN会产生笛卡尔积式膨胀，而UNION ALL方案天然按行去重逻辑更明确
实际用FULL JOIN时，最常被跳过的其实是连接键本身的NULL语义——它既不是“相等”，也不是“不等”，而是“不可比较”。这点不厘清，再漂亮的语法也导出错误数据。
