EXISTS 并非一定比 IN 快，因 MySQL 5.6+ 对 IN 启用半连接优化，而 EXISTS 可能引发 N×M 嵌套循环；性能取决于外层扫描行数、子查询实际返回行数及关联字段索引有效性。
EXISTS 为什么常被误认为一定比 IN 快
很多人一看到“存在性检查”就无脑换 EXISTS，结果反而更慢。根本原因是：MySQL 优化器对 IN 的处理早已不是简单物化子查询——从 5.6 开始，满足条件的 IN 子查询会被自动转成半连接（semi-join），执行计划可能和 JOIN 几乎一样高效。而 EXISTS 强制逐行驱动子查询，如果外层表太大、子查询又没走索引，就会变成 N × M 的嵌套循环扫描。
真正影响性能的三个硬指标
别看“内外表大小”，要看这三个实际可查的量：
-
EXPLAIN中rows列：外层表预估扫描行数（越小，EXISTS越有优势） - 子查询返回行数：用
SELECT COUNT(*)实测，不是“表总行数”，而是WHERE条件过滤后的结果集大小（越小，IN物化开销越低） - 关联字段是否有有效索引：必须是子查询中
WHERE条件里实际用到的列，且类型匹配（比如INT对VARCHAR会失效）
NOT IN 和 NOT EXISTS 的坑必须绕开
NOT IN 在子查询结果含 NULL 时直接返回空集，这是 SQL 三值逻辑导致的，不是 bug，但极易引发线上漏数据。而 NOT EXISTS 完全不受 NULL 影响，语义清晰稳定。
- 错误写法：
WHERE id NOT IN (SELECT user_id FROM orders WHERE status = 'pending')—— 若orders表里某条记录user_id为NULL，整条WHERE条件变UNKNOWN，该行被过滤 - 正确写法：
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = t.id AND o.status = 'pending') - 额外注意：
NOT EXISTS的子查询里必须显式写出关联条件，漏写会导致笛卡尔积
什么时候该强制改写，而不是凭经验猜
当遇到以下任一情况，直接改写并验证，别纠结语法习惯：
- 子查询带聚合（如
GROUP BY或HAVING）——IN无法走半连接优化，EXISTS更可控 - 外层表
rows < 1000且子查询表有复合索引覆盖关联+过滤字段 ——EXISTS的短路机制能省掉大量扫描 - 需要复用同一子查询多次（比如在
SELECT和WHERE都用）—— 改用LEFT JOIN+IS NOT NULL更稳，避免重复执行
真实瓶颈往往藏在 EXPLAIN 的 type 和 Extra 字段里，比如出现 Using temporary 或 Using filesort，说明问题不在 IN 或 EXISTS 本身，而在缺失索引或数据倾斜。
