EXISTS通常比IN快，因其采用短路机制，找到首条匹配即退出；但若子查询无索引、含LIMIT/GROUP BY或外层表大而子查询小时，IN可能更优。
EXISTS 为什么比 IN 更快，但不是总快
EXISTS 在多数场景下确实比 IN 快，前提是子查询能**提前终止**——只要找到一条匹配记录就返回 TRUE，不扫全表。但这个优势只在两种情况下成立：orders.user_id 有索引，或 orders 表本身很小。如果没索引，数据库仍得全表扫描子查询，和 IN 没区别，甚至更慢（尤其 MySQL 5.6 及以前版本优化差）。反过来说，如果外层 users 表很大、子查询 orders 很小，IN 可能反而更稳。
子查询必须显式关联外层表，漏写等于逻辑崩坏
这是最常导致结果全错的硬伤。比如查“至少下过两单的用户”，下面这种写法是错的：
SELECT * FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE COUNT(*) >= 2 -- ❌ 错！没 GROUP BY，COUNT 是整张 orders 表的总数 );
正确写法必须把外层 u.id 拉进子查询的 WHERE 条件，并用 GROUP BY + HAVING：
SELECT * FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id -- ✅ 关键：必须关联 GROUP BY o.user_id HAVING COUNT(*) >= 2 );
- 漏掉
o.user_id = u.id，子查询就变成全局判断，结果要么全返回，要么全不返回 -
HAVING不能直接用外层字段（如HAVING MAX(o.amount) > 100），必须先GROUP BY再聚合 - 子查询里别写
SELECT *或具体字段，统一用SELECT 1或SELECT NULL，语义清晰且避免额外列开销
NOT EXISTS 遇到 NULL 要格外小心
查“从未下单的用户”，直觉写 NOT EXISTS (SELECT 1 FROM orders WHERE user_id = u.id) 是对的；但如果 orders.user_id 允许 NULL，且你误加了 OR user_id IS NULL，整个逻辑就失效——因为 NULL = u.id 永远是 UNKNOWN，不是 FALSE，NOT EXISTS 判定会出错。
安全写法只有两种：
- 确保
orders.user_id是NOT NULL（建表时加约束） - 显式排除
NULL：WHERE user_id = u.id AND user_id IS NOT NULL
否则，哪怕只有一条 user_id 为 NULL 的订单，就可能让某些本该被筛出的用户意外留在结果里。
深层嵌套或复杂条件时，EXISTS 不是万能解
EXISTS 只回答“有没有”，不回答“有多少”或“最大值是多少”。一旦需求超出存在性判断，比如：
- “用户最近一笔订单金额 > 100” → 需要窗口函数或
JOIN+ROW_NUMBER() - “每个用户订单数、平均金额、最新下单时间” → 直接
LEFT JOIN+GROUP BY更清晰 - 嵌套超过两层（如查“有高价值订单的用户的推荐人”）→ 优先考虑 CTE 或临时表，可读性和维护性远高于多层
EXISTS
强行用 EXISTS 套三层以上，不仅难调试，MySQL 或旧版 PostgreSQL 还可能放弃优化，退化成嵌套循环。
