子查询能用上索引，但取决于类型和写法；in、exists、派生表处理逻辑不同，需通过explain format=tree或analyze table验证索引实际使用情况。
子查询能用上索引吗？取决于类型和写法
能，但不是所有子查询都自动走索引。MySQL 对 IN、EXISTS、派生表（FROM (SELECT ...)）的处理逻辑完全不同，索引是否生效要看执行计划里有没有 type=ref 或 range，而不是“写了 WHERE 就一定快”。
常见误区是把 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE status=1) 当成等价于 JOIN，其实 5.7 及以前版本中，如果 t2.status 没索引，整个子查询可能被物化成临时表，再对每行做全表扫描匹配。
-
IN子查询：外层字段有索引 + 内层结果集小（通常 -
EXISTS子查询：只要内层WHERE条件能命中索引（比如EXISTS (SELECT 1 FROM t2 WHERE t2.t1_id = t1.id AND t2.created > '2023-01-01')），就会走ref或range访问 - 派生表（
FROM (SELECT ...)）：5.7+ 默认尝试将派生表合并（derived_merge=on），若无法合并，则生成内部临时表——此时原表索引失效，得靠临时表自身是否有索引（MySQL 不给派生表自动建索引）
EXPLAIN 看不出子查询用了哪个索引？加 FORMAT=TREE
传统 EXPLAIN 输出里，子查询常显示为 <subquery2></subquery2>，看不出具体访问方式。MySQL 8.0+ 必须用 EXPLAIN FORMAT=TREE 才能看到子节点的索引使用细节，比如：
-> Nested loop inner join (cost=2.05 rows=1)
-> Filter: (t1.status = 1) (cost=0.35 rows=1)
-> Table scan on t1 (cost=0.35 rows=1)
-> Index lookup on t2 using idx_user_id (user_id=t1.id) (cost=0.35 rows=1)这里明确指出 t2 走了 idx_user_id 索引。如果是 Using temporary; Using filesort 出现在子查询分支下，基本可判定索引没生效或设计不合理。
- 5.7 用
EXPLAIN EXTENDED+SHOW WARNINGS查看重写后的语句，判断是否被转成 JOIN - 确认索引是否被选中，不能只看
key列非 NULL，还要看rows是否接近实际匹配行数——如果rows=10000但实际只有 5 行满足，说明索引区分度差或统计信息过期 -
ANALYZE TABLE t2强制更新统计信息，尤其在大量 INSERT/DELETE 后
哪些子查询写法必然导致索引失效
以下写法会让 MySQL 放弃使用索引，即使字段本身有索引：
- 子查询里对索引字段做函数操作：
SELECT * FROM t1 WHERE id IN (SELECT CAST(user_id AS CHAR) FROM t2)→user_id索引失效 - 子查询返回多列：
SELECT * FROM t1 WHERE (a,b) IN (SELECT x,y FROM t2)→ MySQL 5.7 不支持多列 IN 的索引下推，8.0+ 需要联合索引且顺序严格匹配 - 子查询含
ORDER BY ... LIMIT但外层没对应排序需求：SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 ORDER BY updated_at DESC LIMIT 10)→ 排序强制生成临时表，索引仅用于排序阶段，不用于外层匹配 - 子查询关联条件未覆盖索引最左前缀：
idx_status_created(status, created)存在，但写成WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.created > NOW())→ 仅用created字段，无法走该联合索引
替代方案：什么时候该放弃子查询改用 JOIN
当子查询出现 DEPENDENT SUBQUERY（依赖子查询）且 rows 值高时，JOIN 通常更稳。但不是所有场景都适合——JOIN 可能放大结果集（一对多时），而 EXISTS 天然去重。
- 一对一或一对零关系（如查用户及其配置）：优先
LEFT JOIN，确保ON条件字段都有索引 - 检查存在性（“有没有订单”）：用
EXISTS，比IN更可控，避免空值陷阱（NULL在IN中永远不匹配） - 需要聚合子数据（如每个用户的最新订单 ID）：别硬套子查询，改用窗口函数（MySQL 8.0+）或先聚合再 JOIN，例如：
SELECT u.*, o.latest_id FROM user u JOIN (SELECT user_id, MAX(id) AS latest_id FROM order GROUP BY user_id) o ON u.id = o.user_id
真正难优化的，往往是嵌套三层以上的子查询，或者子查询里又带子查询。这种结构很难让优化器做出合理选择，拆成临时表或应用层分步查，反而更可靠。
