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或函数时，两者的执行路径可能完全分叉。
