left join 变成 inner join 是因 where 中对右表字段的非空条件过滤了 null 行；正确做法是将右表筛选条件移入 on 子句，确保左表记录全部保留。
LEFT JOIN 变成内连接，不是数据库“偷偷改了”，而是你写的条件位置错了——WHERE里碰了右表字段，就等于主动把 NULL 行全筛掉了。
WHERE 里写了右表字段，LEFT JOIN 就失效
LEFT JOIN 的语义是：左表每行都保留，右表没匹配上就填 NULL。但一旦 WHERE 中出现类似 o.status = 'paid'、d.dim_month > '2025-07' 这种对右表字段的非空判断，所有右表字段为 NULL 的行（即左表没连上的那些）就会被过滤掉，结果只剩左右都匹配的行，等效于 INNER JOIN。
常见错误写法：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
这句实际只返回“有已支付订单的用户”，没订单的用户直接消失。
-
WHERE o.status IS NULL不会退化，它专挑没匹配上的行 -
WHERE o.status = 'paid' OR o.status IS NULL看似想兼顾，但逻辑易漏、可读性差，不推荐 -
WHERE 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（会导致语义混乱，多数引擎不支持）
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，就必须带(+) - 现代 SQL 应优先用标准
LEFT JOIN ... ON，避免(+)带来的隐式陷阱
动态 SQL 和 ORM 场景下最容易踩坑
MyBatis、JDBC 拼接条件时，前端传了 dept_name，后端直接拼进 WHERE，LEFT JOIN 就悄悄失效——开发可能完全没意识到关联语义已变。
更隐蔽的是性能问题：
- 把条件从
WHERE挪到ON后，如果右表缺少对应字段的复合索引（如(status, user_id)），谓词无法下推，扫描量反而增大 - 改写前务必用
EXPLAIN对比执行计划，不能只看语法是否“看起来对” - 尤其在 Hive/Spark SQL 中，
WHERE过滤右表常导致整个右表被提前裁剪，LEFT JOIN 彻底失效
最危险的不是写错，而是查不出错——结果少了行，但没报错、没警告，只有核对业务口径时才发现漏数据。
