EXISTS不一定比IN更快，但多数慢查询优化中换用EXISTS能见效，核心在于它更容易触发半连接并天然支持短路——前提是关联条件写对、索引建对。
EXISTS 不一定比 IN 更快，但多数慢查询优化中换用 EXISTS 能见效，核心在于它更容易触发半连接（semi-join）并天然支持短路——前提是关联条件写对、索引建对。
EXISTS 怎么做到“找到一个就停”
这不是语法糖，是执行模型决定的：数据库把 EXISTS 当作布尔判断，只要子查询返回第一行就返回 TRUE，后续扫描直接跳过。你用 EXPLAIN FORMAT=TREE 能看到 -> Semi-join (duplicate removal)，说明优化器已启用短路路径。
而 IN 配合子查询时，MySQL（尤其 5.7 及更早）默认会物化整个结果集——哪怕子查询只差一行就该命中，它也得先把几万行全扫出来、去重、建哈希表，再对外层逐行探查。
- 常见错误现象：
EXISTS执行计划里出现DEPENDENT SUBQUERY不代表慢，反而是短路生效的标志；IN计划里若出现MATERIALIZED或DERIVED，基本已确认在内存里塞了个临时表 - 子查询带
LIMIT 1对IN无效——优化器不识别这个意图；EXISTS天然就是“找一个就行” - 如果外层表有 10 万行，子查询每行都走一次索引查找（如
ref类型），总开销约O(10^5 × log m)；而IN可能先花 2 秒生成 50 万行临时集，再花 1 秒匹配
为什么加了索引，EXISTS 还是慢成 IN
因为 EXISTS 的性能优势完全依赖关联字段上的有效索引。漏建、建错顺序、或用了单列索引，都会让短路失效，退化为嵌套循环全表扫描。
例如：写 WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')，必须建联合索引 (user_id, status) ——user_id 是驱动字段，必须放最左；只建 (status) 或 (status, user_id)，优化器大概率放弃走索引。
- 检查方法：用
EXPLAIN FORMAT=TREE看子查询部分是否显示using index condition和access_type: ref或range - 容易踩的坑：以为给
orders.status加了索引就够了，没意识到user_id才是关联主键 - 反例：外层表大（200 万行）、子查询只返回 99 行 → 实测
IN快 10 倍，因为IN一次物化 + 主表走索引范围扫描即可，EXISTS却要循环调用 200 万次
NOT IN 为什么必须换成 NOT EXISTS
这不是性能问题，是逻辑陷阱：只要子查询任意一行的字段值为 NULL，整个 NOT IN 表达式就判为 UNKNOWN，WHERE 直接过滤掉所有行——你查不到数据，但不会报错，也看不出 NULL 在哪。
NOT EXISTS 完全不受影响，语义清晰：“主表某行在子查询中找不到匹配即成立”。执行计划上它仍可走索引关联，而 NOT IN 几乎必然触发全表扫描。
- 错误示例：
WHERE c2 NOT IN (SELECT c2 FROM t2)，只要t2.c2有一条NULL，结果永远为空 - 正确写法：
WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.c2 = t1.c2)，无需额外加IS NOT NULL - 即使你手动补
AND c2 IS NOT NULL，维护成本高，且未来加数据仍可能静默崩坏
什么时候 IN 反而更快
当子查询结果极小（几十到几百行）、主表能高效利用索引、且数据库版本较新（MySQL 8.0+）时，IN 可能更优——因为它能被优化器转为常量列表或哈希匹配，避免反复调用子查询。
典型场景：配置表查询、状态码校验、枚举值过滤。比如 WHERE status IN (SELECT code FROM sys_dict WHERE type = 'order_status')，若该子查询只返回 5 行，IN 一次物化后，主表走 ref 查索引即可。
- 关键判断依据：看
EXPLAIN中rows_examined_per_scan——IN的这个值应远小于EXISTS的外层行数 × 内层平均扫描行数 - 别盲目替换：
IN ('paid', 'shipped')这种字面量列表，换EXISTS没意义，还破坏可读性 - 聚合子查询（含
GROUP BY、HAVING、DISTINCT）不能直接套EXISTS，否则语义丢失
真正该盯住的不是 EXISTS 还是 IN，而是执行计划里有没有 Using semi-join；最容易被忽略的不是语法，是关联条件漏写、索引字段顺序颠倒、以及 NOT IN 静默吞掉整张结果集的能力。
