FULL JOIN返回左右表所有记录，不匹配字段填NULL，是LEFT与RIGHT JOIN的并集；MySQL不支持需用UNION模拟，适用于数据比对、审计等场景，但性能差且易误用。
SQL中的FULL JOIN（全连接）会返回左表和右表中所有记录，无论是否匹配。如果某侧没有匹配行，对应字段用NULL填充。它本质是LEFT JOIN与RIGHT JOIN的并集，但需注意数据库兼容性与性能影响。
FULL JOIN的基本语法与执行逻辑
FULL JOIN通过ON子句指定关联条件，结果集包含两表全部行。未匹配的字段补NULL，重复列名需用表别名区分。
- 标准写法：SELECT * FROM A FULL JOIN B ON A.id = B.a_id;
- 等价写法（兼容不支持FULL JOIN的数据库）：SELECT * FROM A LEFT JOIN B ON A.id = B.a_id UNION SELECT * FROM A RIGHT JOIN B ON A.id = B.a_id WHERE A.id IS NULL;
- 注意：MySQL原生不支持FULL JOIN，需用UNION模拟；PostgreSQL、SQL Server、Oracle均支持。
使用FULL JOIN的典型场景
当需要对比两个数据源的完整覆盖情况时，FULL JOIN非常直观。
- 查出所有客户及其订单信息，同时保留从未下单的客户和无客户归属的异常订单
- 合并两个不同系统的用户表，识别双方独有的用户ID（用于同步或清理）
- 审计数据完整性，比如比对生产库与备份库中主键是否存在差异
容易踩的坑与关键注意点
FULL JOIN看似“全面”，但实际使用频率低，主要因语义复杂、性能开销大、且易引发误解。
- NULL判断要谨慎：WHERE子句中若写WHERE B.status IS NOT NULL，会过滤掉左表独有行，实质退化为INNER JOIN效果
- JOIN顺序不影响结果，但会影响可读性——建议把主业务表放LEFT，补充信息表放RIGHT
- 大数据量下性能较差，因需扫描两表全部数据并做笛卡尔式匹配；务必确保ON字段有索引
- 结果行数可能远超任一原表（尤其存在一对多关系时），导出或展示前先COUNT验证
替代方案与优化建议
多数情况下，FULL JOIN可用更明确、更可控的方式代替。
- 用LEFT JOIN + UNION ALL + WHERE IS NULL实现逻辑等价，同时便于分步调试
- 业务上优先考虑是否真需要“两边都保留”——很多时候只需LEFT或RIGHT即可满足需求
- 涉及多表合并时，避免嵌套FULL JOIN，改用CTE分步处理，提升可维护性
- 在WHERE或HAVING中过滤前，先用SELECT COUNT(*)确认FULL JOIN后数据量是否合理
基本上就这些。FULL JOIN不是日常首选，但在数据比对、迁移、审计类任务中确实不可替代——用对了省事，用错了难排查。
