LEFT JOIN中WHERE筛选右表字段会使其退化为INNER JOIN；正确做法是将右表过滤条件移至ON子句，确保左表行不丢失。
LEFT JOIN里WHERE筛右表字段=直接丢左表行
只要WHERE里出现右表字段的非空判断（比如WHERE orders.status = 'paid'），LEFT JOIN就立刻退化成INNER JOIN——不是“看起来像”，是数据库执行时真把没匹配上的左表行全删了。
原因很简单：WHERE作用在JOIN之后的完整结果集上，而右表没匹配上的行，所有字段都是NULL。NULL = 'paid'结果为UNKNOWN，不满足TRUE，整行被剔除。
- 错误写法：
LEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid'→ 没订单的用户彻底消失 - 正确写法：
LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'→ 用户全在，没支付订单的orders.*字段全为NULL - 特别注意：
WHERE orders.id IS NOT NULL和WHERE orders.id IS NULL都安全，但前者等价于INNER JOIN，后者才是找“未匹配项”的合法方式
INNER JOIN中ON和WHERE换位置看似没事，实则埋雷
INNER JOIN下ON a.id = b.id AND b.deleted = 0和ON a.id = b.id WHERE b.deleted = 0通常返回相同结果，但这只是优化器“帮忙重写”的巧合，不是SQL标准保证的行为。
真正危险的是后续变更：如果某天要把这个INNER JOIN改成LEFT JOIN，而b.deleted = 0还留在WHERE里，数据就立刻出错——没人会专门去翻旧WHERE条件。
-
ON里混入业务条件（如b.category = 'A'）可能让优化器无法使用索引，尤其当该字段无索引或类型隐式转换时 - 跨数据库迁移风险高：Presto、老版MySQL对
WHERE条件下推行为不一致，换库后结果可能突变 - 语义污染：
ON本该只表达关联逻辑（外键、分片键），塞进状态字段会让别人读SQL时误判意图
多表LEFT JOIN时ON绑定范围极易被误读
写A LEFT JOIN B ON ... LEFT JOIN C ON ...时，第二个ON只作用于B JOIN C这一步，它能引用A和B的字段，但不能依赖B已被WHERE过滤过——因为WHERE还没执行。
典型错误：想“先筛B再连C”，却把B.flag = 1放在WHERE，结果A有数据、B有数据、但C不满足flag = 1的整行被干掉，而不是只让C字段为NULL。
- 每个
JOIN后必须立刻跟对应的ON，别堆到末尾或靠缩进猜顺序 - 复杂嵌套建议用括号明确优先级：
(A LEFT JOIN B ON ...) LEFT JOIN C ON ... - PostgreSQL对
ON中引用未声明别名报错，MySQL可能容忍但行为不可靠，别依赖
调试时最该先看的不是结果，而是NULL分布
线上LEFT JOIN查不到预期数据，第一反应不该是改条件，而是注释掉WHERE，SELECT *跑一遍，盯着右表字段是不是大面积NULL——如果是，问题八成出在WHERE筛了右表。
执行计划里的filtered值比rows更说明问题：ON条件影响中间结果集大小，WHERE只减少最终输出行数。如果rows远小于左表总数，且用了LEFT JOIN，基本可以锁定是WHERE误触右表字段。
- GORM等ORM生成SQL时，常把关联条件自动塞进
WHERE，必须人工核对是否破坏外连接语义 - 数仓场景下，
s1.month = '2025-04'这种时间条件放WHERE会导致左表部分行丢失，必须挪进对应ON - 最隐蔽的坑：
ON里写b.created_at > '2025-01-01'本身没问题，但如果b.created_at大量为NULL，可能触发全表扫描或索引失效，性能暴跌
