EXISTS通常比IN快，因其采用半连接机制，找到首条匹配即短路退出；但若子查询含LIMIT、GROUP BY等，优化器可能放弃转换，此时IN在小结果集或静态列表中反而更优。
EXISTS 为什么常比 IN 快，但不是永远
EXISTS 天然适合“是否存在”语义，执行时对主表每行只查子查询是否返回至少一行，找到就短路退出；IN 则倾向于先物化子查询结果（尤其非相关子查询），再做集合查找。但 MySQL 5.6+ 会尝试把符合条件的 IN 自动转为半连接，所以实际快慢得看执行计划是否真用了 FirstMatch、Materialization 或 LooseScan。
容易踩的坑：
- 误以为写
EXISTS就一定触发半连接——如果子查询里有LIMIT、GROUP BY、UNION，优化器直接放弃转换 - 在
IN子查询里加DISTINCT或复杂表达式，干扰物化判断，导致降级为嵌套循环 - 用
NOT IN时子查询含NULL，整行被过滤（三值逻辑），而NOT EXISTS不受影响
看 EXPLAIN 才能确认是否走半连接
关键不是语法，是 select_type 和执行策略。MySQL 8.0+ 的 EXPLAIN FORMAT=TREE 最直观；5.7+ 用传统 EXPLAIN 看字段：
-
select_type = DEPENDENT SUBQUERY→ 没优化，逐行执行子查询 -
select_type = SIMPLE且出现FirstMatch(t2)、LooseScan(t2)或Materialize→ 已转半连接 -
Extra里有Using where; Using index是好信号；若出现Using temporary; Using filesort，说明物化或排序开销大
示例：EXPLAIN SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid'); 若 orders(user_id, status) 无复合索引，DEPENDENT SUBQUERY 几乎必然出现。
什么时候该坚持用 IN 而不是 EXISTS
IN 并非过时写法，它在这些场景反而更稳：
- 子查询是静态列表，如
WHERE status IN ('active', 'pending')—— 优化器直接转为哈希查找，没关联、没 NULL 风险 - 子查询结果集小（WHERE dept_id IN (SELECT id FROM depts WHERE region = 'CN')，物化成本低，查找快
- 需要隐式去重：IN 自动对子查询结果去重，而 EXISTS 不关心重复匹配，若业务逻辑依赖“去重后存在”，强行换 EXISTS 可能多出重复行
注意：MySQL 对 IN (subquery) 的物化阈值不固定，受 optimizer_search_depth 和内存限制影响，大结果集仍可能退化。
索引和 NULL 处理才是性能分水岭
无论写 IN 还是 EXISTS，最终性能卡点往往不在语法，而在数据访问路径：
- 关联字段必须有索引，且最好是覆盖索引。例如
EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id AND l.created_at > '2025-01-01')，理想索引是logs(user_id, created_at)，单列user_id索引不够 -
IN遇到子查询返回NULL时，整行结果为UNKNOWN，WHERE 条件失效——这在 LEFT JOIN + WHERE 场景中极易引发漏数据，而EXISTS完全规避此问题 - 若子查询表有大量
NULL值且业务允许，可在子查询中加WHERE col IS NOT NULL提前过滤，减少半连接输入规模
最常被忽略的一点：半连接优化虽好，但 Materialization 策略会把子查询结果写入临时表，若该表过大且磁盘临时目录空间不足，查询会直接失败——这时反而是简单嵌套循环更可靠。
