EXISTS和IN性能取决于执行计划而非语法：半连接（Using semi-join）时EXISTS更优，小结果集+索引时IN更快；NOT IN因NULL逻辑陷阱必须换NOT EXISTS；漏关联条件或缺索引会导致性能断崖下跌。
没有绝对“更高”，效率取决于驱动表大小、子查询结果集大小和索引可用性——直接看执行计划比背口诀管用得多。
怎么看EXISTS和IN是否走了半连接
MySQL 5.6+ 的优化器会主动将符合条件的 EXISTS 重写为半连接（semi-join），但 IN 不一定。关键不是语法，而是执行计划里有没有 Using semi-join 提示。
- 运行
EXPLAIN FORMAT=TREE SELECT ... WHERE EXISTS (...)，如果输出里出现-> Semi-join (duplicate removal)，说明走半连接，只确认存在性，不取值、不回表 - 对等价的
IN查询跑同样命令，如果看到Materialize或Cache，代表它真把子查询结果缓存成临时结构，内存和 CPU 开销都更高 - 注意：哪怕语义等价，只要子查询含
GROUP BY、ORDER BY或无索引字段，IN很可能被降级为嵌套循环或临时表哈希匹配
什么时候IN反而比EXISTS快
常见误区是“EXISTS一定更快”。实际上当子查询结果极小、主表大且有索引时，IN 常胜出。
- 子查询返回几十到几百行（如
SELECT id FROM config WHERE status = 'active'），且主表WHERE id IN (...)能命中id索引 →IN一次索引范围扫描 + 哈希匹配，开销低 - 子查询带
LIMIT 1或确定性条件（如WHERE user_id = ?），IN可能被优化为常量传播，而EXISTS仍按逐行调用逻辑展开 - MySQL 版本较老（如 5.7 之前）且
optimizer_switch='semijoin=off'，EXISTS退化为普通嵌套循环，IN反而更稳
为什么NOT IN必须换成NOT EXISTS
这不是性能问题，是逻辑陷阱。只要子查询结果中任意一行的关联字段为 NULL，NOT IN 整个条件就判为 UNKNOWN，结果集为空——即使你肉眼确认没 NULL，未来加数据也可能静默失效。
-
NOT EXISTS不受NULL影响，语义明确：主表某行在子查询中找不到匹配即返回 - 执行计划上，
NOT EXISTS仍可利用子查询字段上的索引；NOT IN在多数情况下触发全表扫描，且无法使用hash_aj或merge_aj连接 - 即使你加了
IS NOT NULL条件，也建议统一用NOT EXISTS：避免维护负担，执行计划更可预期
最容易被忽略的坑：关联条件漏写或索引缺失
写 EXISTS 时漏掉 WHERE inner.id = outer.id，或关联字段没建索引，会导致性能断崖式下跌——比 IN 还慢。
- 无关联的
EXISTS（如EXISTS (SELECT 1 FROM huge_table)）变成恒真/恒假判断，优化器可能放弃半连接，直接全扫内表 -
EXISTS的子查询字段若无索引，每次循环都变成全表扫描，总成本 ≈ 主表行数 × 内表行数 -
IN的子查询若返回几十万行，内存暴涨、临时表写磁盘、甚至 OOM，比慢还危险
真正决定快慢的从来不是关键字本身，而是驱动顺序、索引覆盖和结果集规模。别猜，EXPLAIN FORMAT=JSON 里盯紧 rows_examined_per_scan 和 using_join_buffer 字段——前者越小越好，后者一出现就得警惕。
