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 的行全筛掉了。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 真正想保留左表全部记录？把过滤条件挪进 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 语义。越“无痛”的改动，越容易在某个凌晨三点的报表里露出马脚。