exists不依赖外表索引，其性能关键在于内表关联字段是否有有效索引；所谓“更容易命中”是误将执行计划中内表索引名当作外表索引，实际外表仍为全量扫描。
EXISTS 不依赖外表索引，但为什么常被误认为“更容易命中”？
这是一个常见误解：EXISTS 本身 并不使用外表索引，它对外表是全量扫描（type: ALL 或 range），真正起作用的是内表索引。所谓“更容易命中外部索引”，其实是把执行计划里 key 列显示的索引名误读成了“外表用了索引”——实际那是内表的索引。
看一个典型例子：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');
执行计划中如果看到 key: idx_user_id_status，这个索引属于 orders 表（内表），不是 users（外表）。而外表 users 的访问方式仍是 type: ALL 或 type: index，除非你额外加了 WHERE 条件且该字段有索引。
IN 为什么反而更依赖外表索引？
IN 的执行分两步：先物化子查询结果（比如 SELECT id FROM orders WHERE status = 'paid'），再拿这个结果集去和外表字段做哈希匹配或排序查找。这时，外表字段是否走索引，直接决定匹配效率：
- 如果外表字段（如
users.id）没有索引，MySQL 只能对每条外表记录做全表扫描式比对，type: ALL出现，性能断崖下跌 - 如果外表字段有索引（如主键或唯一索引），MySQL 可以用
type: eq_ref或type: ref快速定位，匹配开销极低 - 子查询结果集越大，外表没索引的代价越明显——因为要对每一条外表行都查一遍临时哈希表
EXISTS 的“索引友好”其实全靠内表
EXISTS 的性能关键在于子查询能否快速判断“是否存在匹配行”。这完全取决于内表关联条件上的索引是否生效：
- 必须有覆盖关联字段的索引，例如
orders(user_id)或复合索引orders(user_id, status) - 执行计划中看到
Using where; Using index才说明内表走了索引且避免回表 - 如果内表关联字段没索引，EXISTS 会退化为对内表逐行扫描（
type: ALL），外表哪怕只有一行，也要扫完整个内表 - 外表行数越多，这种“嵌套循环 × 内表全扫”的成本越不可控
什么时候你会错觉 EXISTS “用了外表索引”？
两种典型干扰场景：
- 你在外表加了独立过滤条件，比如
WHERE u.status = 'active' AND EXISTS (...)，且u.status有索引——这时key显示的是外表索引，但它是为WHERE服务的，和 EXISTS 无关 - 优化器在 MySQL 8.0+ 启用了
semijoin重写，把 EXISTS 转成半连接，外表可能走range或ref，但这属于优化器行为，不是 EXISTS 语义本身带来的 - 你用
EXPLAIN FORMAT=TREE看到外表节点下挂了索引名，那其实是子查询执行时绑定的内表索引，树形结构容易误导层级归属
真正决定快慢的，永远是「外表行数 × 内表单次查找成本」，而不是外表有没有索引。别被执行计划里一闪而过的 key 名骗了。
