答案是：判断“有没有”应优先用exists而非join。因为exists语义清晰、性能更优、不受null影响，而join用于拼接数据、获取子表字段，二者功能不同、不可互换。
只判断“有没有”，就别用JOIN
当你真正要的只是「某条记录在另一张表里是否存在关联」，比如“查出所有有订单的用户”，EXISTS是更直接、也通常更快的选择。用JOIN硬凑不仅多此一举，还容易引入逻辑错误：一对多时主表行被重复展开，SELECT *会返回冗余数据；若再加DISTINCT去重，CPU和内存开销反而比EXISTS高。
-
EXISTS子查询里写SELECT 1就够了，数据库根本不读字段内容，只看有没有行 - 别把
JOIN当过滤器用——它天生是做数据拼接的，不是做存在性判断的 - 如果业务语句写着“查出所有没下过单的用户”，该用
NOT EXISTS，而不是LEFT JOIN ... WHERE right_table.id IS NULL，后者语义绕、易漏NULL、执行计划更难优化
要取子表字段，JOIN就没得选
EXISTS只返回布尔值，它不提供任何子表数据。一旦你需要订单金额、下单时间、商品名称这些字段，就必须用JOIN（或LEFT JOIN）。这时候纠结“哪个更快”没意义，因为功能不可替代。
-
INNER JOIN适合“必须有关联才保留”的场景；LEFT JOIN才能表达“有就取值，没有就留NULL” - 一对多时，记得提前用
ROW_NUMBER()或LIMIT 1（配合窗口函数）控制子表行数，否则JOIN会把主表行数撑大几倍 - 如果只想要子表最新一条记录，别在
ON里加ORDER BY + LIMIT——多数数据库不支持，应改用JOIN子查询或LATERAL（PostgreSQL）/APPLY（SQL Server）
索引没建对，EXISTS和JOIN一样慢
很多人测出EXISTS比JOIN慢，第一反应是“文档骗人”，其实90%是因为子查询里的关联字段没索引。比如EXISTS (SELECT 1 FROM orders WHERE user_id = u.id)，如果orders.user_id没索引，数据库只能全表扫描每一条匹配，彻底失去短路优势。
-
EXISTS子查询中WHERE条件涉及的字段（尤其是外键）必须有索引 -
JOIN的连接字段两边都建议建索引，特别是右表数据量大时——没索引容易触发嵌套循环，变成O(n×m)级别开销 - 复合索引要注意字段顺序：
(user_id, status)能加速WHERE user_id = ? AND status = 'paid'，但(status, user_id)不行
IN遇到NULL就失效，EXISTS不会
IN在子查询结果含NULL时，整个条件会变成UNKNOWN，导致查不到任何数据；而EXISTS完全不受NULL影响——它只看行存在性，不比较值。这是SQL三值逻辑的硬伤，不是bug。
- 典型翻车现场：
WHERE t1.status IN (SELECT status FROM t2 WHERE t2.active = 1)，只要t2.status有NULL，整条条件失效 -
NOT IN更危险：只要子查询任意一行是NULL，结果恒为空；NOT EXISTS没这个问题 - 修复方式不是加
WHERE status IS NOT NULL（可能漏数据），而是换EXISTS或NOT EXISTS重写逻辑
