LEFT JOIN中ON只决定连接方式，不筛左表行；WHERE在连接后筛选整行，可剔除未匹配行。ON应仅含关联逻辑，WHERE负责业务筛选，二者分工明确不可混淆。
LEFT JOIN里ON条件不能筛掉左表行，但WHERE能
ON条件只管“怎么连”，不决定“留不留”。LEFT JOIN的语义是强制保留左表所有行，哪怕右表没匹配上，也会用NULL填充右表字段。而WHERE是在连接完成后的整行筛选，一旦条件涉及右表字段（比如 o.status = 'paid'），那些右表为NULL的行就全被踢出——左表数据直接消失。
常见错误现象：LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' 看起来想查“所有用户+他们的已支付订单”，实际结果只包含有已支付订单的用户，等价于 INNER JOIN。
容易踩的坑：
- 把业务筛选逻辑（如状态、时间范围）误塞进ON，以为“写了就安全”，却忽略了它本不该承担过滤意图
- 在多表LEFT JOIN中，第二个
ON只能引用前两个表的字段，不能依赖前面WHERE已筛过的左表字段（因为WHERE还没执行） - 某些数据库（如旧版SQLite）不支持
ON里的非等值表达式，AND o.created_at > '2025-01-01'会直接报错
WHERE条件能做ON做不到的事：主动剔除未匹配行
WHERE不是废的，它唯一且不可替代的作用，是基于连接结果做最终裁剪。比如你想找“没下过单的用户”，就得靠 WHERE o.id IS NULL；想查“近7天有下单的活跃用户”，就得先LEFT JOIN再用 WHERE o.created_at >= NOW() - INTERVAL 7 DAY 过滤。
这些操作无法用ON实现，因为ON没有“反向排除”的能力——它只能让右表字段变NULL，不能让整行消失。
使用场景：
-
WHERE t2.id IS NULL：合法且常用，用于识别左表孤立记录 -
WHERE u.status = 'active' AND o.amount > 100：混合筛选，但要注意左表字段条件放WHERE没问题，右表字段条件放这里就会丢数据 - 权限控制类动态条件（如
WHERE u.tenant_id = ?）必须放WHERE，它和连接逻辑无关
INNER JOIN里ON和WHERE效果一样，但语义和风险不同
虽然INNER JOIN a ON a.id = b.id AND b.deleted = 0 和 INNER JOIN a ON a.id = b.id WHERE b.deleted = 0 通常返回相同结果，但这只是优化器“帮忙重写”的表象。
真正危险的是后续演进：
- 哪天把
INNER JOIN改成LEFT JOIN，而b.deleted = 0还留在WHERE里，数据立刻错乱 -
ON里混入无索引的业务字段（如b.category = 'vip'），可能让优化器放弃使用主外键索引，JOIN性能骤降 - 跨库迁移时，Presto或老版MySQL对WHERE条件下推行为不一致，同一SQL换环境结果突变
ON和WHERE的分工边界其实很清晰
别被“都能出结果”迷惑。ON只该出现外键匹配、分片键对齐、主从关系表达式这类纯粹的关联逻辑；WHERE专管时间范围、状态枚举、租户隔离、用户输入参数这些业务层筛选。
最常被忽略的一点是：ON条件影响中间结果集大小，WHERE只影响最终输出行数。EXPLAIN里的filtered值会暴露真实代价——ON早筛一行，后面JOIN计算就少处理几倍数据；WHERE晚筛，数据库可能已经把整个右表都拉进来拼了。
