EXISTS不一定比IN快，关键看子查询是否相关、结果集大小、索引覆盖和执行计划；相关子查询且内表大、关联字段有索引时EXISTS更优，独立子查询且结果集小、外表字段有索引时IN更合适。
EXISTS 通常比 IN 更快，但不是无条件成立——关键看子查询是否能走索引、结果集大小、以及 NULL 处理是否被忽略。
EXISTS 能走索引，IN 却全表扫描
当子查询字段（如 b.id）有索引，而主表关联字段（如 a.ref_id）也有索引时，EXISTS 可以利用索引做“首次匹配即退出”，实际只查几行；IN 子查询若未被优化器转为 Semi-Join，则可能先物化整个结果集，再逐行比对。
- MySQL 8.0+ 和 PostgreSQL 会尝试将简单
IN自动转为 Semi-Join，但前提是子查询不带GROUP BY、HAVING、聚合函数或相关列引用 - Oracle 19c 对
IN的转换更激进，但遇到OR条件或复杂过滤时仍可能失败 - 用
EXPLAIN看Extra列：出现FirstMatch、LooseScan或DuplicateWeedout才说明 Semi-Join 生效；否则就是普通嵌套循环
子查询结果集大，EXISTS 的短路优势才明显
如果子查询返回 50 万行，而主表只有 1 万行，IN 需把这 50 万行加载进临时结构再哈希/排序，EXISTS 则对主表每行只查一次索引，找到第一个匹配就停。
- 典型适用场景：
SELECT * FROM orders WHERE EXISTS (SELECT 1 FROM order_items WHERE order_id = orders.id AND status = 'shipped') - 反例：
SELECT * FROM customers WHERE id IN (SELECT customer_id FROM orders)—— 若orders表中customer_id重复率极高（比如 90% 是同一个 VIP），优化器可能放弃物化，反而退化成全表扫描 - 此时更稳的方案是：先建临时表
CREATE TEMP TABLE tmp_ids AS SELECT DISTINCT customer_id FROM orders，再JOIN，并给tmp_ids.customer_id加主键
NULL 值导致语义漂移，这是最常被跳过的坑
IN 遇到子查询返回 NULL，整个条件直接判假（SQL 标准），哪怕其他值都匹配；EXISTS 完全无视 NULL，只看是否存在行。
- 错误改写示例：
WHERE id IN (SELECT ref_id FROM logs)→ 改成WHERE EXISTS (SELECT 1 FROM logs WHERE logs.ref_id = id)，但如果logs.ref_id允许NULL，原逻辑本意是“排除所有 ref_id 为 NULL 的记录”，新写法却会把它们全放进来 - 安全做法：显式过滤
WHERE ref_id IS NOT NULL，或用LEFT JOIN ... ON ... WHERE ... IS NOT NULL模拟EXISTS且保留对NULL的控制 - PostgreSQL 中还可加
AND ref_id IS NOT NULL在子查询里，避免语义变化
PostgreSQL 用递归 CTE 强制 Semi-Join，绕过优化器失效
当子查询表存在严重数据倾斜（比如 100 万行中只有 12 个唯一 id），而优化器仍坚持全表扫描时，可用递归 CTE 提前提取唯一键值，手动模拟 Semi-Join。
WITH RECURSIVE tmp AS ( SELECT min(id) AS id FROM b UNION ALL SELECT (SELECT min(b.id) FROM b WHERE b.id > tmp.id) FROM tmp WHERE tmp.id IS NOT NULL ) SELECT a.* FROM a WHERE EXISTS (SELECT 1 FROM tmp WHERE tmp.id = a.id);
- 这个技巧不依赖优化器判断，强制只扫描
b表 12 次（等于唯一值数量），而非 100 万次 - 仅适用于子查询目标字段有索引、且唯一值极少的场景；若唯一值达 10 万，递归深度和开销反而上升
- MySQL 不支持这种递归写法，需改用
SELECT DISTINCT+ 临时表替代
真正卡住性能的往往不是语法本身，而是索引缺失、统计信息过期、或误信“EXISTS 一定比 IN 快”这类笼统结论。每次改写前，先跑 EXPLAIN ANALYZE，盯紧实际扫描行数和 Extra 字段——这才是 Semi-Join 是否生效的唯一证据。
