MySQL不支持FULL OUTER JOIN，需用LEFT JOIN与RIGHT JOIN结合UNION ALL模拟：先取左表全量及匹配右表数据，再补右表独有行（WHERE左表ID IS NULL），确保字段对齐、类型一致并用NOT EXISTS防NULL陷阱。
MySQL不支持FULL OUTER JOIN，得用UNION模拟
MySQL从8.0开始仍不支持FULL OUTER JOIN语法，直接写会报错ERROR 1064 (42000)。想查A表有但B表没有、B表有但A表没有、以及两边都有的所有记录，必须用LEFT JOIN + RIGHT JOIN + UNION组合实现。
- 先用
LEFT JOIN查A表全部 + B表匹配部分（含B为NULL的行） - 再用
RIGHT JOIN查B表全部 + A表匹配部分，但要去掉A和B都非NULL的重复行——所以WHERE a.id IS NULL - 最后用
UNION合并，自动去重；若需保留重复行，改用UNION ALL（注意性能开销）
SELECT a.id, a.name, b.order_id FROM users a LEFT JOIN orders b ON a.id = b.user_id UNION SELECT a.id, a.name, b.order_id FROM users a RIGHT JOIN orders b ON a.id = b.user_id WHERE a.id IS NULL;
PostgreSQL和SQL Server可以直接用FULL OUTER JOIN
PostgreSQL 8.3+ 和 SQL Server 2005+ 原生支持FULL OUTER JOIN，写法简洁，语义清晰。但要注意：ON条件只控制连接逻辑，不能过滤掉NULL侧的整行——如果加了WHERE，可能意外丢掉本该保留的“仅一侧存在”的记录。
- 正确做法：把过滤条件写进
ON子句（如ON a.id = b.user_id AND b.status = 'paid'），或在外部再套一层子查询 - 错误写法：
FULL OUTER JOIN ... WHERE b.order_id IS NOT NULL——这会让左表独有行全部消失 - NULL值参与JOIN时，
=比较永远返回UNKNOWN，所以ON a.code = b.code不会匹配两边都是NULL的行；需要等值匹配NULL，得显式写(a.code = b.code OR (a.code IS NULL AND b.code IS NULL))
LEFT JOIN + RIGHT JOIN组合的常见漏判点
用UNION模拟时，字段顺序、类型、别名必须完全一致，否则UNION会失败或隐式转换出错。尤其当两表字段数相同但含义不同（比如都叫id但一个是用户ID一个是订单ID），容易在UNION后混淆归属。
- 务必显式列出字段，不要用
*——SELECT a.id, a.name, b.order_id比SELECT *安全得多 - 对齐字段类型：若
a.name是VARCHAR(50)，b.product_name是TEXT，某些数据库会拒绝UNION，需用CAST(b.product_name AS VARCHAR(50)) - 给NULL占位字段起明确别名，比如
NULL::INTEGER AS order_id（PostgreSQL）或NULL AS order_id（MySQL），避免后续引用歧义
性能比原生FULL OUTER JOIN差，大表慎用
模拟方案实际执行两次JOIN + 一次去重合并，IO和CPU开销明显高于原生FULL OUTER JOIN。当A、B表都超百万行时，UNION的临时结果集排序去重可能成为瓶颈。
- 有索引的前提下，
LEFT JOIN和RIGHT JOIN各自能走索引，但UNION阶段无法利用索引加速 - 若只需“仅A有”或“仅B有”的数据，直接用两个独立查询更高效：
SELECT ... FROM A LEFT JOIN B ... WHERE B.id IS NULL+SELECT ... FROM B LEFT JOIN A ... WHERE A.id IS NULL - MySQL 8.0+ 用户可考虑用CTE +
UNION ALL+ 显式去重逻辑（如ROW_NUMBER()），但复杂度上升，仅当数据量可控时值得尝试
真正要查全集匹配关系时，先确认数据库是否原生支持；不支持就老实用UNION，但字段对齐和NULL处理这两步，跳过一个都会让结果错得悄无声息。
