mysql不支持full outer join，需用left join与right join结合union all模拟：先取左表全量及匹配右表数据，再补右表独有行（where左表id is null），避免重复和null键遗漏。
FULL OUTER JOIN 在多数主流 SQL 引擎中不被原生支持——MySQL 直接报错，SQLite 默认不支持，只有 PostgreSQL、SQL Server、Oracle 等少数数据库能直接用。
MySQL 怎么模拟 FULL OUTER JOIN
MySQL 没有 FULL OUTER JOIN 语法，必须用 LEFT JOIN + RIGHT JOIN + UNION ALL 拼接。关键是避免重复主键为 NULL 的交集行，所以得用 WHERE right_table.id IS NULL 过滤右表独有部分，再用 WHERE left_table.id IS NULL 过滤左表独有部分。
常见错误是直接 UNION 导致去重误删数据，必须用 UNION ALL；另一个坑是没加 IS NULL 条件，导致交集部分被重复计算两次。
示例（合并 users 和 orders）：
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 处理陷阱
PostgreSQL 支持标准 FULL OUTER JOIN，但结果里左右表都缺失的字段会是 NULL，容易在后续 WHERE 或聚合中引发意外过滤。比如写 WHERE amount > 100，会自动排除右表独有行（因为 amount 是 NULL），实际想查的是“订单金额超 100 或用户无订单”就得改成 WHERE amount > 100 OR amount IS NULL。
另外注意：连接条件列若本身允许 NULL，FULL OUTER JOIN 可能产生笛卡尔式膨胀——比如两表都有多条 id IS NULL 记录，就会交叉匹配。
安全做法是提前 COALESCE 或在 ON 子句中排除 NULL 值：
SELECT COALESCE(u.id, o.user_id) AS user_id, u.name, o.order_id FROM users u FULL OUTER JOIN orders o ON u.id = o.user_id AND u.id IS NOT NULL AND o.user_id IS NOT NULL;
为什么不能用 LEFT JOIN + RIGHT JOIN 直接替代 FULL OUTER JOIN
表面看 LEFT JOIN 和 RIGHT JOIN 能覆盖两边，但直接拼接会漏掉一种情况：当连接键在两表中都为 NULL 时，LEFT JOIN 和 RIGHT JOIN 都不会匹配这些行（SQL 标准中 NULL = NULL 为 UNKNOWN，不成立）。而 FULL OUTER JOIN 会把双方都为 NULL 的行也当作“匹配”并保留。
也就是说，如果你的业务数据里存在合法的空关联键（比如未绑定用户的临时订单），仅靠左右连接模拟会丢失这部分记录。
真正等价的模拟必须显式补上这部分：
SELECT u.id, u.name, o.order_id, o.amount FROM users u FULL OUTER JOIN orders o ON u.id = o.user_id; -- 等价于（含 NULL 键处理）： 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 UNION ALL SELECT NULL, NULL, o.order_id, o.amount FROM orders o WHERE o.user_id IS NULL AND NOT EXISTS (SELECT 1 FROM users u WHERE u.id IS NULL);
性能和索引影响比你想象中更严重
FULL OUTER JOIN 无法利用单边索引高效驱动——它必须扫描两表全量数据，再做哈希或归并匹配。即使连接列上有索引，优化器也大概率放弃使用，转为全表扫描后排序/哈希。在千万级表上，响应时间可能从毫秒级跳到数秒甚至超时。
如果只是想“查出所有用户及其订单（含无订单用户）+ 所有订单（含无用户订单）”，更优解通常是分两步查：SELECT ... FROM users LEFT JOIN orders + SELECT ... FROM orders WHERE user_id NOT IN (SELECT id FROM users)，后者可走 user_id 索引，整体更快更可控。
还有一个现实问题：很多 ORM（如 Django ORM、SQLAlchemy 默认配置）根本不生成 FULL OUTER JOIN 语句，强行手写可能绕过缓存、日志或权限控制逻辑。
真正需要 FULL OUTER JOIN 的场景其实很少，多数时候是需求理解偏差——先确认是否真的要“两边完全独立补全”，而不是“以某一方为主，另一方可选填充”。
