深层嵌套子查询慢是因为每层相关子查询被外层每行重复执行，无法复用结果；最内层可能触发n×m次扫描，且默认物化为无索引临时表，导致全表扫描；优化器对超两层嵌套常放弃semi-join优化，explain中大量dependent subquery、rows飙升、using temporary; using filesort频现；压平为join是最快解法，前提是等值关联，需确保连接字段有索引、避免函数干扰，并优先消灭相关子查询。
深层嵌套子查询为什么慢得像卡住
因为 MySQL 对每一层相关子查询都可能重复执行，且无法复用中间结果。比如三层嵌套中，最内层子查询可能被外层每行数据触发执行 N×M 次，而不是只执行一次；同时每层子查询的结果都默认物化为无索引的临时表，导致后续连接或过滤全靠全表扫描。
更麻烦的是，优化器对超过两层的嵌套往往放弃半连接（semi-join）优化，EXPLAIN 里会看到大量 DEPENDENT SUBQUERY，rows 列数值飙升，Extra 里频繁出现 Using temporary; Using filesort。
把三层子查询压平成 JOIN 是最快解法
只要子查询之间是“等值关联”关系（比如 WHERE id IN (SELECT ...) 或 EXISTS (SELECT ... WHERE t1.x = t2.y)），就几乎总能重写为多表 JOIN。关键不是“能不能”，而是“必须做”。
- 先用
EXPLAIN确认哪一层是瓶颈：看select_type列，DEPENDENT SUBQUERY出现次数越多、对应rows越大，那一层越该优先拆 - 把最内层子查询单独拎出来，作为派生表（
FROM (SELECT ...) AS t），并确保它的WHERE条件字段有索引 - 外层逐级用
JOIN替代IN/EXISTS，连接条件必须和原子查询里的等值条件完全一致 - 避免在
JOIN条件中使用函数或表达式，否则索引失效——例如把ON o.user_id = UPPER(u.id)改成ON o.user_id = u.id
非相关子查询可用物化 + 索引兜底
如果某层子查询不依赖外层（即 select_type 是 SUBQUERY 而非 DEPENDENT SUBQUERY），它本该只执行一次，但若返回结果集大（比如几万行），MySQL 仍可能把它存成磁盘临时表，拖慢整体速度。
- 给子查询涉及的过滤字段加索引，比如
SELECT id FROM logs WHERE status = 'error' AND created_at > '2026-01-01'，就要在(status, created_at)上建联合索引 - 强制物化为内存临时表：在子查询外加
/*+ NO_MERGE() */提示（MySQL 8.0.22+），防止优化器错误地将它“下推”进外层导致重复计算 - 如果结果集实在太大（> 10 万行），不如直接用
CREATE TEMPORARY TABLE显式建表，并在关键字段上加索引，再参与后续JOIN
相关子查询必须消灭，不能“优化”只能“替换”
这是最容易被误判的一点：很多人试图给相关子查询加索引、改写 IN 为 EXISTS，但只要它还是相关子查询，就逃不开“外层 N 行 → 内层执行 N 次”的本质。真正的解法只有两个：彻底转为 JOIN，或用窗口函数替代（MySQL 8.0+）。
- 典型陷阱语句：
SELECT * FROM orders o WHERE (SELECT COUNT(*) FROM items i WHERE i.order_id = o.id) > 5—— 这种必须改成LEFT JOIN ... GROUP BY ... HAVING COUNT(*) > 5 - 涉及聚合或排序的场景（如“查每个用户最新一条订单”），优先用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，比任何子查询都稳 - 如果业务逻辑真需要“逐行判断+动态子查询”，说明数据模型可能已偏离范式，该考虑预计算字段或冗余统计表了
真正难处理的不是语法怎么写，而是识别出哪些子查询表面“无关”，实则因隐式类型转换（比如 INT 字段和 VARCHAR 字段比较）被迫变成相关子查询——这种问题不会报错，但会让 EXPLAIN 里的 select_type 突然变成 DEPENDENT SUBQUERY，极难察觉。
