嵌套查询性能取决于每层索引是否有效：最内层WHERE字段必须有索引，主查询关联字段也需索引；避免子查询中使用函数导致索引失效；优先用EXISTS替代IN并确保外键组合索引；派生表涉及GROUP BY等操作时，对应字段须建索引；三层以上嵌套需逐层验证EXPLAIN中key列是否命中索引。
WHERE 中的子查询必须走索引，否则变成全表扫描
嵌套查询在 WHERE 里用 IN 或 = 引用子查询结果时，数据库会先执行子查询，再拿结果去主表过滤。但如果子查询本身没走索引，或者主查询的关联字段没索引，整个链路就容易退化成双重全表扫描。
常见错误现象：EXPLAIN 显示子查询的 select_type 是 DEPENDENT SUBQUERY，且 Extra 出现 Using where; Using temporary —— 这说明它每行都触发一次子查询，且无法利用索引快速定位。
- 确保子查询的
WHERE条件字段有单列或组合索引（比如SELECT id FROM users WHERE status = 'active'，就要给status建索引） - 主查询中用于匹配子查询结果的字段（如
order_id IN (subquery)），该字段本身也得有索引 - 避免在子查询里用函数或表达式做条件，例如
WHERE YEAR(create_time) = 2023会让create_time索引失效
用 EXISTS 替代 IN 时，外键字段索引是关键
EXISTS 比 IN 更适合大数据量场景，但它的性能优势完全依赖于内层查询能否快速“短路判断”——也就是找到一条匹配就退出。这只有在内层查询能用上索引时才成立。
典型陷阱：写成 WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')，但 orders 表没在 (user_id, status) 上建组合索引，导致每次都要扫描大量订单。
- 组合索引顺序必须匹配查询模式：等值条件字段放前，范围或排序字段放后，例如
CREATE INDEX idx_orders_user_status ON orders(user_id, status) - 如果子查询只查存在性，不需要返回具体值，就别在
SELECT里写*或多余字段，写SELECT 1即可 - 注意 MySQL 8.0+ 对
EXISTS的半连接优化（semijoin）默认开启，但前提是索引可用；若发现执行计划里出现FirstMatch或LooseScan，说明优化生效
FROM 中的派生表必须有索引支撑，否则聚合变瓶颈
把子查询放在 FROM 里当临时表（派生表），看似解耦了逻辑，但如果这个子查询本身要聚合、排序、去重，而底层表缺乏对应索引，就会在物化阶段卡住。
比如：SELECT u.name, t.total FROM users u JOIN (SELECT user_id, SUM(amount) total FROM payments GROUP BY user_id) t ON u.id = t.user_id —— 如果 payments 表没在 user_id 上建索引，GROUP BY 就只能走文件排序，内存溢出风险高。
- 对派生表中涉及
GROUP BY、ORDER BY、DISTINCT的字段，务必提前建索引 - MySQL 5.7+ 会尝试将派生表自动合并（
derived_merge=on），但前提是子查询不包含聚合或窗口函数；若想强制物化，可加SELECT * FROM (SELECT ... ) AS t并在外部加JOIN，此时索引更关键 - PostgreSQL 中派生表默认不物化，但若子查询含
LIMIT或复杂 CTE，仍需靠索引加速内部扫描
嵌套层级超过两层时，索引要覆盖最内层筛选条件
三层嵌套不是不能用，但每多一层，索引失效风险就翻倍。比如 WHERE x IN (SELECT y FROM t1 WHERE y IN (SELECT z FROM t2 WHERE z > ?))，最内层 t2.z > ? 若没索引，第二层 t1.y 就算有索引也白搭——因为输入集太大。
真实案例中，某订单系统三层嵌套查“客户所在城市中消费最高的商品”，结果响应从 200ms 拉到 4s，最后发现 cities 表的 region_id 缺少索引，导致中间层扫描了 80 万行。
- 逐层检查
EXPLAIN输出，确认每一层的key列都有实际使用的索引名 - 优先给最内层子查询的
WHERE字段建索引，再向上补全连接字段索引 - 若某层子查询返回结果集过大（> 数千行），考虑改用临时表 + 显式索引，而不是依赖优化器自动物化
索引对嵌套查询的加速效果，从来不是“建了就灵”，而是取决于哪一层、哪个字段、在什么操作下真正被用上。最容易被忽略的是：子查询内部的筛选条件是否独立可索引，以及外层如何引用它的输出——这两点一旦断开，整条链路就退回原始暴力扫描。
