LEFT JOIN后WHERE过滤右表字段会使连接退化为INNER JOIN；正确做法是将右表筛选条件移至ON子句，如ON t1.id = t2.t1_id AND t2.status = 'active'，以确保左表全量保留。
直接改 INNER JOIN 为 LEFT JOIN 是最常见但最容易出错的做法——它看似无痛，实则可能让查询结果翻倍、NULL 值暴增、业务语义彻底跑偏。关键不在语法替换，而在判断「哪张表该保全」「哪些字段允许为 NULL」「WHERE 条件是否还在偷偷过滤掉 OUTER 行」。
LEFT JOIN 后 WHERE 条件会悄悄吃掉 NULL 行
这是线上事故最高发的点。比如原 INNER JOIN 查询是：
SELECT b.branch_name, a.area_name FROM branch b INNER JOIN area a ON b.area_no = a.area_no;
改成 LEFT JOIN 后如果沿用旧 WHERE：
SELECT b.branch_name, a.area_name FROM branch b LEFT JOIN area a ON b.area_no = a.area_no WHERE a.area_name LIKE '%华%';
结果和 INNER JOIN 几乎一样——因为 WHERE a.area_name LIKE ... 把所有 a.area_name IS NULL 的行全筛掉了。
- 真正想保留左表全部记录？把过滤条件挪进
ON：ON b.area_no = a.area_no AND a.area_name LIKE '%华%' - 只想查“没匹配到区域”的机构？用
WHERE a.area_no IS NULL，且确保前面没其他WHERE干扰 - 多个 OUTER JOIN 时，每个
ON必须独立约束，不能把右表条件堆在最后的WHERE里
INNER JOIN 改 LEFT JOIN 时必须重审字段来源
原 INNER JOIN 下所有字段天然非 NULL（只要连接键非空），但 LEFT JOIN 后右表字段可能为 NULL，下游代码或报表很可能崩。
- 检查所有 SELECT 中来自右表的字段：比如
a.area_name、a.DHQ，确认业务逻辑能否容忍NULL - 聚合函数如
COUNT(a.area_no)和COUNT(*)含义不同，前者跳过 NULL，后者统计所有行 - 排序时
ORDER BY a.area_name会让NULL排最前或最后（取决于数据库默认行为），需显式写ORDER BY a.area_name NULLS LAST（PostgreSQL）或等效写法
MySQL 不支持 FULL OUTER JOIN，但业务真要“两边都保全”怎么办
当需要同时保留左表无匹配 + 右表无匹配的记录（比如比对两个系统数据差异），MySQL 没有 FULL OUTER JOIN 语法，硬写会报错。
- 用
LEFT JOIN + RIGHT JOIN + UNION拼接（注意去重）： (SELECT b.*, a.* FROM branch b LEFT JOIN area a ON b.area_no = a.area_no) UNION (SELECT b.*, a.* FROM area a LEFT JOIN branch b ON a.area_no = b.area_no WHERE b.area_no IS NULL)- 更稳妥的方式是用
UNION ALL加标识字段区分来源，避免隐式去重导致漏数据 - 如果只是临时分析，优先考虑应用层合并，而非强行 SQL 实现——复杂度和可读性常得不偿失
真正麻烦的从来不是改一个关键字，而是改完之后没人再看一眼执行计划、没人验证 NULL 是否被下游消费、没人检查 WHERE 是否已悄然破坏 OUTER 语义。越“无痛”的改动，越容易在某个凌晨三点的报表里露出马脚。
