exists和in性能差异关键看子查询结果集大小及索引利用：子查询大、外层表小时exists更快；子查询小且mysql 8.0+时in可能更优；NULL处理、缺失索引、数据倾斜才是真实瓶颈。
EXISTS 和 IN 在什么情况下性能差别最明显
关键看子查询结果集大小和是否能利用索引。当子查询返回大量行、且外层表小，EXISTS 通常更快；反过来，子查询结果很小（比如几十行），IN 可能更优，尤其 MySQL 8.0+ 对 IN 做了物化优化。
但真实瓶颈往往不在语法本身，而在缺失索引或数据倾斜。比如 WHERE id IN (select user_id FROM logs)，如果 logs.user_id 没索引，IN 会全表扫描子查询结果再哈希匹配，而 EXISTS 可能走 logs 上的联合索引快速定位。
- 外层表小、子查询大 → 优先
EXISTS - 子查询是静态值列表（如
IN (1,2,3)）→IN更直观，无性能差异 - 子查询含
GROUP BY或聚合 →EXISTS通常更稳，IN可能因去重逻辑多走一步 - postgresql 中
IN子查询若返回NULL，整个条件判为UNKNOWN，结果为空 —— 这不是性能问题，但会让结果“消失”得莫名其妙
MySQL 里 IN 被自动转成 EXISTS 的边界在哪
MySQL 5.6+ 引入了“半连接优化（semi-join）”，对某些 IN 子查询会自动改写为 EXISTS 或物化表。触发条件包括：子查询无相关列、不包含聚合、不带 ORDER BY / LIMIT。
但只要子查询里引用了外层字段（即相关子查询），就无法被优化，只能老老实实嵌套执行。比如：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = orders.region) —— 这个 orders.region 让优化器放弃转换，性能直接掉档。
- 检查执行计划时重点看
type列：出现DEPENDENT SUBQUERY就说明没走优化，大概率慢 -
EXISTS写法天然就是相关子查询，反而更容易被索引驱动 - 用
EXPLAIN format=TREE（MySQL 8.0+）能看清是否发生了 semi-join 改写
PostgreSQL 中 NOT IN 和 NOT EXISTS 为什么结果不同
根本原因是 NULL 处理逻辑不同。NOT IN 遇到子查询返回任意 NULL，整个表达式结果为 UNKNOWN，该行被过滤掉；而 NOT EXISTS 完全不关心 NULL，只看是否存在匹配行。
比如 SELECT * FROM users WHERE id NOT IN (SELECT owner_id FROM posts)，只要 posts.owner_id 里有一个 NULL，整条语句查不到任何用户 —— 这不是 bug，是 SQL 标准定义的行为。
- 永远别在可能含
NULL的列上用NOT IN，改用NOT EXISTS - 如果坚持用
NOT IN，必须显式排除：WHERE id NOT IN (SELECT owner_id FROM posts WHERE owner_id IS NOT NULL) - PostgreSQL 的
NOT IN执行计划常显示Hash Anti Join，看着高效，但NULL一搅和，结果就不可信
什么时候干脆别纠结 EXISTS/IN，换 JOIN 更合适
当你需要从子查询里取字段、或要基于子查询结果做分组/排序时，硬套 EXISTS 或 IN 反而绕路。JOIN 更直白，优化器也更好发力。
比如查“有订单的用户及其最新订单时间”，用 EXISTS 只能判断“有没有”，还得额外子查询取时间；而 INNER JOIN + 窗口函数或 DISTINCT ON（PostgreSQL）一次搞定。
- 要拿子查询里的数据 → 用
JOIN，别用EXISTS/IN - 要避免重复行又不想去重逻辑写在应用层 →
JOIN配合GROUP BY或DISTINCT - MySQL 5.7 以前对
IN子查询的缓存很弱，反复执行同一子查询可能比等价JOIN慢几倍
真正卡住性能的，往往不是 EXISTS 和 IN 之争，而是没意识到子查询结果能不能走索引、有没有 NULL 干扰语义、或者根本选错了关联模型。