EXISTS只能靠内表索引是因为其执行逻辑为外表逐行驱动、子查询相关关联，外表仅提供参数不参与内表过滤，故外表索引不影响子查询效率；真正决定性能的是内表关联字段（如o.user_id）是否命中索引。
EXISTS 为什么只能靠内表索引，外表索引基本没用
因为 EXISTS 是相关子查询，执行时 MySQL 会对外表（主查询）逐行扫描，每扫一行，就把该行字段值代入子查询中执行一次。整个过程是「外表驱动 + 内表查找」，外表只是提供参数，不参与子查询的过滤或连接匹配——所以外表字段有没有索引，对子查询执行效率几乎无影响。
真正决定速度的是：子查询里被 WHERE 引用的字段（比如 o.user_id = u.id 中的 o.user_id）是否命中索引。若没索引，每次都要全表扫 orders 表；有联合索引如 INDEX(user_id, status)，就能快速定位并短路退出。
- 外表索引只影响主查询扫描本身（比如
users表按id排序快不快），不影响子查询执行成本 - 子查询中若漏写关联条件（如写成
WHERE o.status = 'paid'而没加o.user_id = u.id），就退化成非相关子查询，可能返回全量结果，逻辑错误 -
SELECT 1是惯用写法，比SELECT *或SELECT id更轻量，MySQL 不解析列内容，只判是否有行
IN 子句依赖外表字段索引做哈希匹配
IN 先执行子查询、物化结果集（比如 SELECT id FROM categories WHERE type = 'digital' 返回 20 行），再拿这个集合去和外表字段做等值匹配。这时，外表字段（如 products.category_id）是否建了索引，直接决定匹配阶段是走索引查找还是全表扫描。
如果 products.category_id 没索引，EXPLAIN 里会出现 type: ALL 和 Extra: Using where，性能断崖下跌；有索引则能快速定位每条匹配记录，哪怕外表有百万行。
- 子查询结果集必须单列，且不能含 NULL（否则整个 IN 条件可能判为 UNKNOWN）
- 子查询若含
ORDER BY或LIMIT，会阻止物化优化，退回到 DEPENDENT SUBQUERY 模式 - 子查询结果超阈值（默认约 1000 行），优化器可能放弃物化，改用嵌套循环，此时外表索引也救不了
看 EXPLAIN 才能确认索引到底有没有生效
光看语句结构猜不准，必须跑 EXPLAIN FORMAT=TREE（MySQL 8.0+）或传统 EXPLAIN，重点盯三列：
-
type：外表是否为ref/range（说明用了索引）；子查询是否为eq_ref或ref（说明内表索引生效） -
key：实际使用的索引名，为空就代表没走索引 -
Extra：出现Using where; Using index表示覆盖索引；出现Using temporary或Start temporary表示触发了物化
特别注意：select_type = DEPENDENT SUBQUERY 是 EXISTS 的常见信号，但不等于慢——只要对应行的 key 非空、rows 很小，就是健康状态。
最容易被忽略的索引陷阱
很多人给子查询表加了索引，却忘了字段顺序和覆盖范围。例如子查询是 SELECT id FROM orders WHERE user_id = ? AND status = 'paid'，只建了 INDEX(user_id) 是不够的——status 过滤没进索引，仍要回表或全扫。
- 必须建联合索引，且等值字段放前面：
INDEX(user_id, status) - 如果子查询还选了其他列（如
SELECT order_no），而你只想避免回表，就得把order_no加进索引尾部，形成覆盖 - 函数或表达式会让索引失效：
WHERE user_id + 0 = u.id或UPPER(email) = ?都无法走索引
索引不是建了就自动生效，它得在执行路径里被真正“触达”。而 EXISTS 和 IN 触达索引的位置完全不同——一个靠内表，一个靠外表，这点一旦混淆，调优就南辕北辙。
