MySQL 不支持 FULL OUTER JOIN，需用 LEFT JOIN 加 RIGHT JOIN 再 UNION ALL 模拟；关联条件必须写 ON 中，右表过滤条件也应放 ON 里避免 NULL 行丢失；注意字段类型一致、索引优化及 NULL 判断须用 IS NULL。
MySQL 不支持 FULL OUTER JOIN，得用 LEFT JOIN + RIGHT JOIN + UNION ALL
MySQL 直到 8.0.32 都没原生 FULL OUTER JOIN，强行写会报错 ERROR 1064。想模拟全外连接，核心思路是：把左表的全部记录（含右表无匹配的）和右表的全部记录（含左表无匹配的）拼起来，再去重重复的交集部分。
实操建议：
- 用
LEFT JOIN获取「左表全量 + 右表匹配项」，其中右表字段为NULL的行代表左独有 - 用
RIGHT JOIN获取「右表全量 + 左表匹配项」，其中左表字段为NULL的行代表右独有 - 两者
UNION ALL（不是UNION），避免隐式去重导致交集行丢失 - 注意两子查询的列数、顺序、类型必须严格一致，否则
UNION ALL报错ERROR 1222
示例（模拟 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; WHERE 条件写在 ON 还是 WHERE 子句里，结果天差地别
在 LEFT JOIN 或 RIGHT JOIN 拼接时，过滤条件放错位置会导致「本该保留的 NULL 行被意外筛掉」，全外连接结果就残了。
实操建议：
- 关联条件（比如
u.id = o.user_id）必须写在ON后，这是决定怎么连的逻辑 - 对右表的过滤（比如
o.status = 'paid'）如果写在WHERE，会把左表中对应右表为NULL的行也干掉——这违反全外连接“保留所有”的本意 - 正确做法：把右表过滤条件挪进
ON，如ON u.id = o.user_id AND o.status = 'paid' - 同理，左表过滤条件若用于
RIGHT JOIN分支，也要塞进ON
性能比原生 FULL OUTER JOIN 差很多，大表慎用
手写 UNION ALL 方案本质是跑两次 JOIN + 一次合并，IO 和 CPU 开销翻倍，尤其当左右表都上百万行时，执行时间可能从秒级变成分钟级。
实操建议：
- 确保关联字段（如
user_id）有索引，否则两个 JOIN 都会变全表扫描 - 如果只是查「某类缺失数据」，比如「有用户但没订单」，直接用
LEFT JOIN …… WHERE order_id IS NULL更快，别硬套全外模板 - PostgreSQL / SQL Server 用户请直接用原生
FULL OUTER JOIN，语法干净、优化器友好 - MySQL 8.0+ 若走
EXPLAIN发现Using temporary; Using filesort，说明UNION ALL中间结果没走索引，得检查字段类型是否隐式转换（比如VARCHAR对INT）
NULL 值判断要小心，IS NULL 不能写成 = NULL
在 RIGHT JOIN 分支里筛选「左表无匹配」时，常见错误是写 WHERE u.id = NULL，结果永远没数据——因为 NULL 不能用等号比较。
实操建议：
- 任何地方判断空值，必须用
IS NULL或IS NOT NULL - 不要依赖
COALESCE(u.id, 0)后再比较，既慢又可能和真实0冲突 - 如果业务允许，可在建表时给关联字段加
NOT NULL约束，减少 NULL 处理分支
真正麻烦的是多字段联合判断空（比如 u.id IS NULL AND u.name IS NULL），这时候容易漏条件，建议先用单字段验证逻辑通不通。
