LEFT JOIN 中右表过滤条件必须写在 ON 而非 WHERE，否则 NULL 行被过滤导致逻辑错误；EXISTS 比 JOIN 更安全、语义更清晰，避免行数膨胀与 NULL 陷阱。
JOIN 的 ON 和 WHERE 混用直接改写语义
LEFT JOIN 后把右表过滤条件写在 WHERE 里，等于悄悄把它变成 INNER JOIN。比如 LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，所有没订单的用户都会被过滤掉——因为 o.status 是 NULL，NULL = 'paid' 为 UNKNOWN，整行被丢弃。
正确做法是把 o.status = 'paid' 移到 ON 子句： LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。否则你以为在查“所有用户 + 他们的已支付订单”，实际只查出了“有已支付订单的用户”。
- ON 是连接逻辑，决定哪些右表行能连上来
- WHERE 是最终过滤，对连接后的结果生效
- 一旦右表字段出现在 WHERE 中，NULL 行必然消失
一对多关系下 JOIN 自动放大主表行数
用 INNER JOIN orders 查“有订单的用户”，如果一个用户有 5 笔订单，结果里就会出现 5 行相同用户数据。而 EXISTS 天然只返回布尔值，主表行数永远不变。
这种膨胀不是性能问题，是逻辑错误：你本想统计“多少用户下过单”，却写了 COUNT(*) FROM users u JOIN orders o ON u.id = o.user_id，结果得到的是订单数，不是用户数。
- 必须加
DISTINCT u.id或GROUP BY u.id才能修正，但额外开销和出错概率都上升 -
EXISTS不需要去重，语义更贴近原始意图 - 若后续还要加其他 JOIN（比如再连
order_items），行数可能指数级膨胀
NULL 值让 NOT IN 和 LEFT JOIN 逻辑失效
NOT IN (SELECT id FROM users) 只要子查询结果里有一个 NULL，整个条件就恒为 FALSE，查不到任何数据。这不是 bug，是 SQL 三值逻辑的硬约束。
有人试图补救：WHERE id NOT IN (SELECT id FROM users WHERE id IS NOT NULL)，但这会漏掉业务上合法的 NULL 用户 ID（比如未实名用户）。而 NOT EXISTS 完全不受影响，它只看“是否存在匹配行”，不比较值。
-
LEFT JOIN ... WHERE right.id IS NULL同样要求右表连接字段非 NULL，否则IS NULL判定不可靠 - 若右表字段允许 NULL，必须额外加
AND right.id IS NOT NULL，否则逻辑错误 -
NOT EXISTS单条语句、零额外条件，天然安全
EXISTS 写错是语法/逻辑错，JOIN 写错常是隐性语义错
EXISTS 子查询漏写关联条件（比如写成 SELECT 1 FROM orders WHERE status = 1 而没写 o.user_id = u.id），执行计划里会出现 DEPENDENT SUBQUERY 消失，变成一次性判断——要么全查出来，要么全不查，结果一眼就能发现不对。
但 JOIN 错了往往“看起来对”：少个 ON 条件可能变成 CROSS JOIN，行数爆炸却没报错；ON 里多加了个条件可能筛掉部分数据，但业务指标波动不明显，几周后才发现漏了某类用户。
- JOIN 错误更难被测试覆盖，尤其在数据分布不均时
- EXISTS 的短路特性也让执行计划更可预测，索引缺失时容易暴露问题
- 真正难的不是写对 JOIN，而是每次写之前都得问一句：“我到底要的是存在性，还是字段值？”
