EXISTS 通常比 IN 更快，但仅当子查询字段有索引或结果集较小时成立；必须关联外层表，否则逻辑错误；NOT EXISTS 需注意 NULL 处理；深层嵌套应改用 CTE 或临时表。
EXISTS 比 IN 更快，但只在子查询有索引或结果集小时才成立
很多人一看到“条件查找”就本能写 IN，比如查“有订单的用户”：SELECT * FROM users WHERE id IN (SELECT user_id FROM orders)。这在 orders.user_id 没索引、或订单表超大时，会全表扫描子查询多次，性能崩得很快。
换成 EXISTS 后，数据库能提前终止——只要找到一条匹配记录就返回 TRUE，不关心有多少条。但前提是子查询里用到的字段（比如 user_id）必须有索引，否则照样慢。
-
EXISTS不返回值，只判断“是否存在”，天然适合布尔逻辑场景 - 子查询必须关联外层表，否则变成恒真/恒假（常见坑：
SELECT * FROM users WHERE EXISTS (SELECT 1 FROM orders)—— 这会返回所有用户） - 如果子查询要查多个字段做条件（比如“用户最近一笔订单金额 > 100”），
EXISTS就不够用了，得切回JOIN或窗口函数
关联子查询里别漏写 WHERE 中的关联条件
这是最常导致结果错得离谱的硬伤。比如想查“至少下过两单的用户”，写成：
SELECT * FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE COUNT(*) >= 2 -- ❌ 错！COUNT 在无 GROUP BY 时是聚合整张 orders 表 );
正确写法必须把外层 u.id 拉进子查询的 WHERE：
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，子查询就脱离上下文，变成全局判断 -
EXISTS子查询里不能直接用外层表字段做聚合条件（如HAVING MAX(o.amount) > 100），得先GROUP BY再HAVING - 某些旧版 MySQL（5.6 及以前）对关联子查询优化差，可能比等价的
JOIN慢几倍，上线前务必EXPLAIN
NULL 值会让 NOT EXISTS 行为反直觉
查“从未下单的用户”，直觉写 NOT EXISTS (SELECT 1 FROM orders WHERE user_id = u.id) 是对的；但如果 orders.user_id 允许 NULL，且你误写了 WHERE user_id = u.id OR user_id IS NULL，整个逻辑就垮了——因为 NULL = u.id 永远为 UNKNOWN，不是 FALSE，NOT EXISTS 判定会出错。
-
NOT EXISTS安全的前提是子查询的关联字段非空，或你在WHERE里显式排除NULL（如WHERE user_id = u.id AND user_id IS NOT NULL） - 如果源表字段可能为空，更稳妥的是用
LEFT JOIN ... WHERE o.id IS NULL替代NOT EXISTS，语义更清晰，执行计划也更容易预测 - PostgreSQL 对
NULL的三值逻辑处理更严格，MySQL 8.0+ 开始也趋同，别依赖“好像没报错”就认为逻辑正确
嵌套太深时，EXISTS 的可读性和维护性反而下降
当你要查“用户所在城市有活跃门店，且该用户近 30 天有订单，且订单中至少有一笔含促销商品”，三层 EXISTS 套娃会让 SQL 难以调试、难加索引、难改需求。
- 超过两层嵌套，优先考虑拆成临时表或 CTE（
WITH），尤其是中间结果要复用时 - 每个
EXISTS子查询应独立可测试：单独运行子查询部分，确认返回行数和字段逻辑是否符合预期 - 别为了“看起来高效”硬套
EXISTS——如果业务要求返回子查询里的字段（比如最新订单时间），强行用EXISTS就得额外再查一遍，反而多一次 I/O
复杂嵌套里，性能瓶颈往往不在语法选择，而在索引覆盖是否完整、统计信息是否过期、或者隔离级别锁住了子查询路径。写完先看 EXPLAIN ANALYZE，而不是先猜哪个关键字“更高级”。
