LEFT JOIN加WHERE后变INNER JOIN是执行顺序导致的必然结果：先连接生成含NULL的中间结果，再由WHERE过滤掉右表字段为NULL的行；正确做法是将右表筛选条件移入ON子句。
LEFT JOIN 加 WHERE 后变 INNER JOIN，不是数据库“优化”或“bug”，而是执行顺序和 NULL 过滤的必然结果。
WHERE 里写了右表字段，LEFT JOIN 就失效
LEFT JOIN 的语义是：左表每行都保留，右表没匹配上就填 NULL。但 SQL 执行顺序是先完成连接（生成含 NULL 的中间结果），再执行 WHERE 过滤。一旦 WHERE 中出现对右表字段的非空判断，比如 o.status = 'paid'、d.dim_month > '2025-07'，所有该字段为 NULL 的行——也就是左表没连上右表的那些——全被筛掉。
常见错误写法：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
这句实际只返回“有已支付订单的用户”，没订单的用户直接消失。
-
o.status IS NULL不会退化，它专挑没匹配上的行 -
o.status = 'paid' OR o.status IS NULL看似兼顾，但逻辑易漏、可读性差，不推荐 -
u.created_at > '2025-01-01'安全，因为只过滤左表
右表筛选条件必须挪进 ON 子句
想保留左表全部记录，同时只关联满足条件的右表数据，就得把右表的业务条件写进 ON，而不是 WHERE。
正确写法：
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' 是关联逻辑的一部分：只把已支付的订单连上来，没订单或订单未支付的用户仍保留，o.amount 为 NULL。
- 多层
LEFT JOIN时，每层右表的条件都要收进各自的ON，例如LEFT JOIN order_items oi ON o.id = oi.order_id AND oi.category = 'electronics' -
ON后可用AND连多个条件，但不能用OR（多数引擎不支持，语义混乱） - 动态 SQL 场景（如 MyBatis）特别容易踩坑：前端传了
dept_name，后端直接塞进WHERE，LEFT JOIN 就悄悄变成 INNER JOIN
Oracle (+) 语法漏写 (+) 也会退化
迁移到金仓（KES）或兼容 Oracle 语法的数据库时，如果沿用 (+) 写法，漏掉任何一个右表字段后的 (+)，都会让 LEFT JOIN 变成 INNER JOIN。
错误写法：
SELECT * FROM t1, t2 WHERE t1.id = t2.id(+) AND t2.name = 'cc';
这里 t2.name = 'cc' 没加 (+)，优化器把它当作连接后过滤，NULL = 'cc' 判定为 UNKNOWN，整行被剔除。
正确写法：
SELECT * FROM t1, t2 WHERE t1.id = t2.id(+) AND t2.name(+) = 'cc';
所有右表字段参与的条件，只要不是 IS NULL 或 IS NOT NULL，都必须带 (+)。
真正难的不是改写语法，而是识别哪些条件属于“右表业务筛选”、哪些属于“左表数据范围”。尤其在嵌套查询或视图中，WHERE 里的字段来源可能不直观；更隐蔽的是性能问题——条件挪进 ON 后，若右表缺少对应复合索引，谓词下推可能失效，查询反而变慢。所以每次调整前，必须看 EXPLAIN 输出。
