MySQL优化器将IN转为EXISTS是因半连接优化生效：当IN子查询非相关、无聚合/LIMIT/ORDER BY、关联字段有索引且版本≥5.6时，优化器主动启用Semi-Join策略，实现匹配即停；否则退化为DEPENDENT SUBQUERY。
MySQL优化器把IN转成EXISTS，是因为半连接优化生效了
这不是“有时随机转换”，而是优化器在满足条件时主动启用半连接（Semi-Join）策略的结果。当 IN 子查询是非相关子查询、无聚合、无 GROUP BY、关联字段有索引，且 MySQL 版本 ≥ 5.6 时，优化器大概率会将它重写为等价的半连接执行路径——而该路径的底层行为和 EXISTS 高度一致：匹配即停、不物化全量结果。
什么情况下IN不会被转成EXISTS？
常见失效场景包括：
-
IN子查询里用了SELECT *或带函数的列（如SELECT UPPER(name)），导致无法做去重/短路判断 - 子查询含
ORDER BY、LIMIT或DISTINCT，破坏了半连接的前提假设 - 外层 WHERE 条件与子查询之间没有可下推的等值关联（比如
WHERE id IN (SELECT id FROM t2 WHERE status = 'x')，但t2.status没索引） - 统计信息过期或
innodb_stats_auto_recalc=OFF，让优化器误判驱动表大小
怎么看优化器到底有没有转？
执行 EXPLAIN FORMAT=TRADITIONAL 后盯紧 Extra 列：
- 出现
Using where; FirstMatch(table_name)或LooseScan：说明已走半连接，逻辑接近EXISTS - 出现
MATERIALIZED或DEPENDENT SUBQUERY：没转成功，还在逐行执行原始IN -
type是ref/range且rows很小，但Extra为空：可能是优化器走了隐式半连接，但没打日志提示
改写成EXISTS后反而变慢，最可能漏了什么？
不是语法写错，而是索引没对上：
- 原
IN子查询走的是orders(user_id)索引，但改成EXISTS后，WHERE o.user_id = u.id实际查的是orders表的user_id字段——如果该字段没索引，EXISTS就退化成全表扫描 - 复合条件没覆盖索引，例如
WHERE o.user_id = u.id AND o.status = 'paid'，但只建了(user_id)单列索引，没建(user_id, status) -
EXISTS子查询里用了SELECT *，旧版本 MySQL（如 5.7）可能因此放弃半连接优化路径
真正卡住性能的，从来不是 IN 还是 EXISTS 的写法选择，而是关联字段有没有索引、索引是否能支撑 ref 访问类型、以及 EXPLAIN 里 rows 预估是否真实反映扫描量。
