full join 语义即“两边全保留，不匹配处填 null”，结果行数=左表+右表−匹配行，空值多说明其正常工作；误将右表条件放 where 会使其退化为 inner join，应移入 on 或显式允许 null。
Full JOIN天生就会产出NULL
不是写法错了，也不是数据坏了——FULL JOIN 的语义就是“两边都要，没匹配上的就填 NULL”。它不筛选、不丢行，左表有 100 行、右表有 80 行，且只有 30 行能匹配，那结果就是 150 行：100 + 80 − 30 = 150，其中 70 行至少一侧字段为 NULL。
这和 LEFT JOIN 或 RIGHT JOIN 不同：后两者只保证一边不丢，而 FULL JOIN 是双向兜底。所以空值多，恰恰说明它按设计在工作。
- 只要两表存在不重叠的主键/关联键范围，就必然产生
NULL -
ON条件越严格（比如加了额外过滤），匹配行越少，NULL越密集 - 如果两表完全无交集（例如
users.id和orders.user_id完全不重合），结果里所有字段将一半来自左表、一半来自右表，中间全是NULL
COALESCE不是万能胶，但它是第一道防线
直接 SELECT * 看到满屏 NULL，别急着改逻辑——先用 COALESCE 控制输出。它不改变数据，只让结果可读、可算。
常见误用是只套一个字段：COALESCE(t1.name) 没意义，必须提供备选值：
- 数值类优先补
0：COALESCE(t1.amount, t2.amount, 0) - 字符串类按业务补占位符：
COALESCE(t1.email, t2.email, '未登记') - 多表字段合并时注意顺序：
COALESCE(t1.id, t2.ref_id)表示“优先取左表 ID，没有再取右表引用 ID” - 避免嵌套过深：
COALESCE(COALESCE(a,b),c)可简化为COALESCE(a,b,c)
WHERE子句一动，FULL JOIN就变INNER JOIN
这是最隐蔽也最致命的坑：把本该写在 ON 中的右表条件，错放进 WHERE，结果所有含 NULL 的行被清零。
例如想查“所有用户 + 所有订单，但只看状态为 'paid' 的订单”，错误写法：
SELECT * FROM users u FULL JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
这个 WHERE 会过滤掉所有 o.status IS NULL 的行，即左表有、右表无匹配的用户全部消失——FULL JOIN 彻底失效。
- 正确做法：把条件塞进
ON：ON u.id = o.user_id AND o.status = 'paid' - 若真需保留左表空匹配，又想筛右表，得显式允许
NULL：WHERE o.status = 'paid' OR o.status IS NULL，但要确认业务是否接受这种逻辑 - 用
EXPLAIN看执行计划，如果type显示ALL且rows异常高，大概率是条件位置错了
性能差不是借口，而是优化信号
FULL JOIN 在 MySQL 早期版本甚至不支持，PostgreSQL/SQL Server 支持较好，但代价明确：它必须扫描两张表的全部数据，无法像 INNER JOIN 那样提前剪枝。
当发现查询慢 + 结果空值多，优先检查三件事：
- 关联字段有没有索引？
EXPLAIN中key列为空，说明没走索引，立刻建 - 是否真需要
FULL JOIN？多数报表场景可用(SELECT ... FROM t1 LEFT JOIN t2 ...) UNION ALL (SELECT ... FROM t2 LEFT JOIN t1 WHERE t1.id IS NULL)替代，可控性更强 - 数据量是否过大？先用
LIMIT测速，再加WHERE过滤主键范围（如u.id BETWEEN 1000 AND 2000），避免全表扫
真正难处理的不是空值本身，而是把 NULL 当成“没数据”去统计，或在排序时默认让它排最前——这些细节不显眼，却会让下游报表逻辑全线偏移。
