LEFT JOIN后WHERE中对右表字段的非空判断会使结果等效于INNER JOIN，因为SQL执行顺序是先JOIN生成含NULL的中间结果，再WHERE过滤，导致右表为NULL的行被全部筛除；正确做法是将右表筛选条件移入ON子句。
LEFT JOIN后WHERE里写了右表字段，结果就变INNER JOIN了
不是数据库“偷偷改写”SQL，而是执行顺序决定的：先完成LEFT JOIN（生成含NULL的中间结果），再执行WHERE过滤。一旦WHERE中出现对右表字段的非空判断，所有右表为NULL的行全被筛掉——左表没匹配上的那些行就消失了。
常见退化写法：
-
WHERE t2.status = 'paid'→NULL = 'paid'为UNKNOWN，整行丢弃 -
WHERE t2.created_at > '2025-01-01'→NULL不满足任何比较，照样丢 -
WHERE t2.id IS NOT NULL→ 直接等效INNER JOIN
唯一安全的右表WHERE条件是t2.id IS NULL，它专用来查“左有右无”的数据，不会破坏语义。
ON里加右表条件，才能保住LEFT JOIN语义
把筛选逻辑从WHERE挪到对应LEFT JOIN的ON子句里，才是正确做法。这时条件只控制“哪些右表行能连上来”，不影响左表保留。
例如：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
这样，o.status = 'paid'只影响订单是否参与连接；没订单或订单状态不是'paid'的用户，o.amount仍为NULL，左表数据完整保留。
注意：
- 多层
LEFT JOIN时，每层右表的业务条件都得收进各自的ON，比如LEFT JOIN order_items oi ON o.id = oi.order_id AND oi.category = 'electronics' -
ON里不能对左表加“必须成立”的限制（如AND u.deleted = 0），虽然语法合法，但实际不改变左表保留逻辑，反而容易误导人 - 别用
COALESCE(t2.status, 'inactive') = 'active'这类写法——COALESCE在ON里对NULL右表行无效，它根本不会参与匹配
动态SQL场景下最容易踩坑
MyBatis、JDBC拼条件时，前端传了个dept_name参数，后端直接塞进WHERE，LEFT JOIN就悄悄变成INNER JOIN，但开发可能完全没意识到关联语义已变。
更隐蔽的是性能问题：
- 把条件从
WHERE挪到ON后，如果右表没建(cal_dt, dim_month)这类复合索引，谓词无法下推，查询反而变慢 - 改写前必须看
EXPLAIN，不能只盯语法 - 某些数据库（如SQL Server）在优化阶段会主动将带右表
WHERE的LEFT JOIN重写为INNER JOIN，执行计划里能直接看到驱动表变化
LEFT JOIN结果重复膨胀，和“变INNER JOIN”是两回事
有人把结果行数变多误认为“变成了INNER JOIN”，其实是另一类问题：右表本身有重复数据，导致左表一行被展开成多行。
例如：
SELECT * FROM a LEFT JOIN b ON a.id = b.a_id LEFT JOIN c ON a.id = c.a_id
若b有2条匹配a.id的记录、c也有2条，则结果是4行（2×2），不是笛卡尔积，而是关联链式展开。
解决方法不是改JOIN类型，而是：
- 提前对
b、c去重（DISTINCT或GROUP BY） - 按需聚合后再关联，比如
SELECT ..., SUM(b.amount) FROM ... GROUP BY b.a_id - 避免在明细层直接关联多对多关系
真正容易被忽略的，是执行顺序这个底层事实：无论你写得多像LEFT JOIN，只要WHERE碰了右表字段且非IS NULL，它就在逻辑上不再是左连接了——这不是bug，是SQL标准规定的执行契约。
