EXISTS对外表逐行做布尔判断，只关心是否存在匹配；IN先物化子查询结果集再枚举比对，要求子查询单列且受NULL影响大。NOT IN遇NULL返回空结果，NOT EXISTS无此问题。
EXISTS 和 IN 的执行逻辑完全不同
别被“都是子查询”骗了——EXISTS 是对外表逐行做「是否存在匹配」的布尔判断，而 IN 是先把子查询结果全捞出来，再做「值是否在集合中」的枚举比对。
这意味着：EXISTS 不关心子查询返回多少行，只要有一行就为真；IN 却必须把整个子结果集加载进内存（或临时表），再挨个比较。
-
EXISTS对外部表是 loop + 内部表索引查找（只用到内表索引） -
IN实际走的是 hash join 或物化临时表，内外表都可能用上索引 - 子查询字段数限制：
IN要求子查询**只能返回一列**；EXISTS无此限制（哪怕写SELECT 1、SELECT *都合法）
什么时候该用 EXISTS，而不是 IN？
关键看数据规模对比：不是看两张表谁大谁小，而是看「外表行数」vs「子查询结果集大小」。
- 子查询结果集很大（比如几十万 ID），但外表很小（比如几百条用户记录）→ 优先用
EXISTS，避免把大结果集全拉出来 - 子查询结果集很小（比如
SELECT id FROM status WHERE type = 'active'只返回 5 条），外表却很大（百万级订单）→ 用IN更快，优化器容易走外表索引 + 内表等值查找 - 子查询涉及
NULL值时，IN会出逻辑陷阱（1 IN (1, NULL)返回NULL，不是TRUE），而EXISTS完全不受影响
SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM users u WHERE u.id = o.user_id AND u.status = 'active' );
NOT IN 和 NOT EXISTS 的坑比想象中深
这是线上最容易翻车的点：NOT IN 遇到子查询里任意一个 NULL，整条语句直接返回空结果集，不是你想要的「排除」，而是「全丢弃」。
-
NOT IN (1, 2, NULL)→ 对任何非 NULL 值都判定为UNKNOWN，WHERE 条件不成立 -
NOT EXISTS没这个问题，它只关心「有没有匹配行」，NULL不干扰逻辑 - 即使子查询加了
WHERE col IS NOT NULL，优化器也不一定能把这个过滤下推，风险仍在
结论：只要涉及否定逻辑，无条件选 NOT EXISTS，别碰 NOT IN。
别信“EXISTS 一定比 IN 快”的谣言
MySQL 8.0+ 的优化器已经很聪明，但它的选择仍高度依赖统计信息和实际数据分布。盲目替换可能适得其反。
- 用
EXPLAIN看执行计划：关注type（是否为index/range）、rows（预估扫描行数）、Extra（有无Using where; Using index） - 真实压测比理论更重要：在目标数据量级下，用
BENCHMARK()或慢日志采样对比耗时 - 如果子查询带聚合或复杂条件（如
GROUP BY+HAVING），IN往往更稳定；EXISTS在这类场景下可能退化成多次全表扫描
真正可靠的策略不是记口诀，而是查 EXPLAIN、看 rows、测真实数据——尤其当子查询里有 JOIN 或函数时，两者的执行路径可能完全分叉。