exists不一定比in快，仅当子查询相关、内表有索引、只关心存在性且执行计划显示短路时才提速；盲目替换易致全表扫描或语义错误，须用explain验证type、rows和extra。
EXISTS 不一定比 IN 快，盲目替换反而更慢甚至查错数据；真正提速只发生在特定条件下：子查询必须关联外层表、内表有索引、你只关心“是否存在”，且执行计划里能看到短路行为。
为什么直接把 IN 换成 EXISTS 常常没用甚至更慢
很多人改写时只做一步：WHERE id IN (SELECT ref_id FROM t2) → WHERE EXISTS (SELECT 1 FROM t2)，结果子查询彻底脱离外层上下文，变成对 t2 的全表扫描。
- 漏掉关联条件（如
t2.ref_id = t1.id），子查询就恒为真或恒为假，数据库对主表每行都返回相同结果 -
SELECT *或SELECT ref_id在子查询里毫无意义，应统一改成SELECT 1，减少字段解析开销 - 原
IN子查询若本身不相关（比如WHERE status IN ('a','b','c')），换EXISTS属于画蛇添足，语义变复杂还难读 - MySQL 8.0+ 和 PostgreSQL 会自动将简单
IN转为 Semi-Join，手动换EXISTS可能绕过优化器，反而退化为嵌套循环
什么情况下 EXISTS 真正比 IN 快
关键不是语法，而是执行路径是否发生改变。必须同时满足：
- 子查询是「相关子查询」：
WHERE条件里明确引用外层字段，例如WHERE o.customer_id = c.id - 内表（子查询涉及的表）在关联字段上有索引，比如
customers(id)或复合索引(country, id) - 你只关心“有没有匹配”，不依赖子查询返回的具体值（
EXISTS完全忽略SELECT后面的内容） - 子查询结果集较大（比如占主表行数 >10%），而主表相对较小——这时
IN的物化开销（建临时表、去重、哈希查找）开始明显拖累
典型有效场景：SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM order_items oi WHERE oi.order_id = o.id AND oi.status = 'shipped')。只要 order_items(order_id) 有索引，数据库大概率对每条 orders 行只查一次索引，找到首条匹配即停。
改写后必须验证的三件事
不跑 EXPLAIN 就上线，等于蒙眼调优。
- 盯
type列：EXISTS版本里子查询部分应出现ref或range，而不是ALL；若仍是DEPENDENT SUBQUERY，说明关联条件没生效或索引未命中 - 比
rows预估数：IN版本中子查询的rows是它要扫描的总行数；EXISTS版本中同一位置的rows应显著变小（理想是接近 1），表示短路起效 - 看
Extra列：MySQL 出现FirstMatch、LooseScan或DuplicateWeedout才说明 Semi-Join 生效；否则仍是朴素嵌套循环
最容易被跳过的是统计信息过期：改完 SQL 后如果没 ANALYZE TABLE 或等自动更新，执行计划可能还在用旧的基数估计。
NOT IN 必须换成 NOT EXISTS
这是最危险也最容易被忽略的坑：NOT IN 遇子查询返回 NULL，整个条件恒为 UNKNOWN，结果集为空——哪怕其他值完全匹配。
- 示例：
WHERE customer_id NOT IN (SELECT referrer_id FROM referrals)，只要referrals.referrer_id里有一个NULL，整条查询就查不到任何记录 -
NOT EXISTS完全不受NULL影响，逻辑稳定 - 即使子查询当前不含
NULL，也建议统一用NOT EXISTS，避免未来数据变更引发隐性故障
真正卡住性能的往往不是语法写法，而是索引缺失或统计信息不准；没在 orders.customer_id 上建索引，EXISTS 和 IN 一样慢。
