LEFT JOIN 后WHERE过滤右表字段会隐式转为INNER JOIN，因NULL值不满足条件而剔除左表无匹配记录；正确做法是将右表筛选条件移至ON子句。
LEFT JOIN 后 WHERE 子句过滤右表字段，导致隐式转为 INNER JOIN
这是 SQL 中最常被忽略的语义陷阱：明明写了 LEFT JOIN，结果查出来的左表记录却“少了一半”——根本原因就是 WHERE 条件里写了右表的非空约束（比如 WHERE t2.status = 'active'）。SQL 执行顺序是先 JOIN 再 WHERE，而 LEFT JOIN 生成的右表字段在无匹配时为 NULL，NULL = 'active' 永远不成立，整行被 WHERE 过滤掉。
-
WHERE t2.id IS NOT NULL、WHERE t2.name != 'xxx'、WHERE t2.created_at > '2023-01-01'—— 全部会剔除左表无匹配的记录 - 真正想保留左表全部记录，又只取右表满足条件的部分，必须把条件移到
ON子句里：LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active' - 注意：放在
ON的条件只影响连接逻辑；放在WHERE的条件作用于最终结果集，且对右表字段的任何非空判断都会消灭NULL行
ON 和 WHERE 放右表条件的区别，看执行结果就明白
假设 t1 有 3 行，t2 只有 1 行匹配 t1.id = 1 且 status = 'active'。下面两段 SQL 看似等价，结果完全不同：
SELECT t1.id, t2.status FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'active';
→ 只返回 1 行（t1.id = 1），其他两行因 t2.status 为 NULL 被 WHERE 过滤
SELECT t1.id, t2.status FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active';
→ 返回 3 行：t1.id = 1 对应 t2.status = 'active'；t1.id = 2 和 3 对应 t2.status = NULL（未被过滤）
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
LEFT JOIN 多表时，WHERE 条件容易误伤更早的左表
当写成 t1 LEFT JOIN t2 ON ... LEFT JOIN t3 ON ...，如果在 WHERE 里加了 t2.col = xxx，不仅会过滤掉 t2 为空的行，还会连带让 t3 的关联失效——因为 t2 记录已被 WHERE 删掉，t3 就失去了连接基础。
- 多表
LEFT JOIN链中，每个右表的筛选条件都应尽量放在对应ON子句里 - 若必须用
WHERE做全局过滤（比如查“所有订单中，用户状态为 active 的订单”），请确认是否真要排除用户为空的订单；否则应改用ON+OR t2.id IS NULL等逻辑补全 - MySQL 8.0+ 和 PostgreSQL 支持
LATERAL，可更清晰地表达“先过滤右表再连接”，但兼容性和可读性不如直接调整ON
怎么快速发现这个错误？
最简单的自查方式：把原查询的 WHERE 条件注释掉，只留 LEFT JOIN 和 SELECT，对比行数变化。如果行数明显减少，且减少部分恰好对应右表无匹配的左表记录，基本就是这个坑。
- 检查执行计划：
EXPLAIN结果中若出现type: ALL或rows明显少于左表基数，结合WHERE内容判断 - 在
WHERE中显式允许NULL：WHERE (t2.status = 'active' OR t2.status IS NULL)能绕过问题，但语义已变，慎用 - 使用
COUNT(*)和COUNT(t2.id)对比：若两者相差大，说明大量右表字段为NULL却又被WHERE过滤了
真正难的不是写对语法，而是意识到 LEFT JOIN 的“左表全量”承诺，会被一行 WHERE 不经意撕毁——尤其当 SQL 是多人协作拼出来的，或者从 INNER JOIN 改过来忘了动条件位置时。
