应优先用EXISTS/NOT EXISTS替代LEFT JOIN+IS NULL做存在性判断，因其更轻量、语义清晰、避免NULL陷阱；需取从表字段或聚合时才必须用JOIN。
用 EXISTS 替代 LEFT JOIN + IS NULL 做存在性判断
当目标只是确认“某条主记录是否关联有满足条件的从表数据”，EXISTS 通常比 LEFT JOIN 更轻量、更直观，且数据库优化器更容易走半连接（semi-join）路径。
比如查“有至少一条已发货订单的用户”：
SELECT u.id, u.name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'shipped' );
这个写法不产生冗余行，不拖带订单字段，也不受 NULL 干扰——EXISTS 只关心子查询能否返回任意一行，返回 TRUE/FALSE 即可。
-
EXISTS不要求子查询返回具体值，SELECT 1比SELECT *更安全，避免列名歧义或隐式转换 - 子查询中
WHERE条件必须显式关联外层表（如o.user_id = u.id），否则变成非相关子查询，逻辑全错 - 若从表无索引，
EXISTS仍会全表扫描；务必在orders(user_id, status)上建复合索引 - MySQL 8.0+ 对
EXISTS有物化优化，但 PostgreSQL 和 SQL Server 在此场景下原生支持更好
用 NOT EXISTS 替代 LEFT JOIN + IS NULL 做反向存在性过滤
查“从未下单的用户”时，NOT EXISTS 是最贴近语义、也最不易出错的写法。它天然规避了 LEFT JOIN 后把 WHERE o.id IS NULL 错写成 ON 或漏加条件导致逻辑翻车的问题。
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
注意：这和 NOT IN (SELECT user_id FROM orders) 完全不同——后者遇到 orders.user_id 有 NULL 就整个条件判为 UNKNOWN，结果为空集。
-
NOT EXISTS对空集返回TRUE，对非空集返回FALSE，三值逻辑清晰可控 - 不能把
NOT EXISTS子查询挪到FROM中当派生表用，否则语义失效 - 如果业务要求“排除最近30天登录过的用户”，记得把时间条件写进子查询的
WHERE，而非外层
为什么不该在存在性场景硬套 LEFT JOIN
LEFT JOIN 的本意是“保留左表全部，右表匹配不上就补 NULL”，但它被滥用作存在性过滤时，常因细节失控导致性能或结果偏差。
- JOIN 后若没加
WHERE过滤，会返回大量重复主表行（一个用户多笔订单 → 多行），后续还得DISTINCT或聚合，徒增开销 - 把过滤条件误写在
WHERE而非ON（例如WHERE o.status = 'shipped'），会让LEFT JOIN实际退化为INNER JOIN，漏掉本该保留的 NULL 行 - 即使正确写了
ON ... AND o.status = 'shipped'，优化器也可能放弃哈希连接，回退到嵌套循环，尤其当右表无合适索引时 - 视图定义中若含此类 LEFT JOIN，每次调用都会强制展开，无法复用中间结果，吞吐量直线下滑
什么时候必须退回 JOIN？
存在性只是起点。一旦你需要从从表取字段、做聚合、或按从表条件排序，EXISTS 就无能为力了，此时得老实用 JOIN。
例如：“列出每个用户最新一笔已发货订单的编号和时间”——EXISTS 只能告诉你“有”，但拿不到“哪一笔”。这时要先用窗口函数或子查询定位最新订单，再 JOIN 关联用户信息。
- 需要返回从表字段（如订单号、金额、时间）→ 必须 JOIN
- 需要统计每个用户的订单总数、平均金额 → 必须 GROUP BY + JOIN 或子查询聚合
- 需要按从表字段排序（如按最后下单时间倒序）→ 外层 ORDER BY 无法引用
EXISTS子查询中的列 - 子查询本身含聚合或
GROUP BY→ 已超出EXISTS支持范围，直接报错
真正难的不是语法替换，而是分清“我到底只需要知道有没有，还是得拿到具体是什么”。很多性能问题，根源都在第一步没想清楚。
