执行计划是优化嵌套查询的首要依据，EXPLAIN可识别重复执行、全表扫描、缺失索引等真瓶颈；CTE需注意物化行为差异；相关子查询改LEFT JOIN需谨慎处理NULL与一对多语义；临时表适用于中等规模中间结果复用。
先看执行计划，别急着重写
多层嵌套查不出结果或慢得离谱，第一反应不该是“怎么拆”，而是确认数据库到底在干什么。EXPLAIN 或 EXPLAIN ANALYZE（PostgreSQL）能暴露真实瓶颈：是不是某层子查询被反复执行？有没有意外的全表扫描？有没有缺失索引导致嵌套循环爆炸？
常见误判：看到三层 SELECT ... FROM (SELECT ... FROM (SELECT ...)) 就觉得“肯定要扁平化”，但有时外层只是加个 WHERE 过滤，而内层已用上索引——强行拆反而破坏优化器选择的执行路径。
用 CTE 替代括号嵌套，但注意物化行为
WITH 语句不是语法糖，它会改变查询生命周期。PostgreSQL 默认可能物化 CTE（即先算完再用），而 SQL Server 和 MySQL 8.0+ 则倾向内联展开——这直接影响性能和结果一致性（比如含 RANDOM() 或 NOW() 的 CTE 可能被多次求值）。
实操建议：
- MySQL 8.0+ 中，
WITH多数情况等价于子查询，可放心替换提升可读性 - PostgreSQL 若 CTE 被引用多次且结果集不大，物化反而是优势；但若只引用一次，加
MATERIALIZED或NOT MATERIALIZED显式控制 - 避免在 CTE 中写
SELECT *，字段越明确，后续 JOIN 或过滤时优化器越容易下推条件
把相关子查询转成 LEFT JOIN，警惕 NULL 语义变化
像 WHERE id IN (SELECT user_id FROM logs WHERE action = 'login') 这类，看起来是嵌套，实际是半连接；而 SELECT ..., (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_cnt 是典型相关子查询，每行都触发一次内层扫描。
改成 LEFT JOIN 通常更高效，但必须注意：
- 原查询返回 0 行时，
JOIN后可能变成多行（因一对多），需配合GROUP BY或DISTINCT - 子查询返回
NULL时，LEFT JOIN会保留左表行并补NULL，语义一致；但若子查询用WHERE ... IS NOT NULL过滤，JOIN 后得补ON ... AND o.id IS NOT NULL才等价 - MySQL 5.7 对相关子查询优化较差，这类改写收益明显；而 PostgreSQL 12+ 已支持将部分相关子查询自动转为 JOIN，手动改前先
EXPLAIN
临时表不是银弹，但适合中间结果复用
当某层嵌套结果要被多个地方引用（比如既用于主查询又用于排序、又用于窗口函数），且数据量中等（几万行以内）、生命周期短，CREATE TEMP TABLE 比反复计算更稳。
关键细节：
- PostgreSQL 临时表默认事务级，断开连接即删；SQL Server 需显式
DROP TABLE #tmp - 建临时表后立刻
CREATE INDEX（尤其 JOIN 或 ORDER BY 字段），否则跟没建一样 - MySQL 不支持临时表加索引（除非用
ENGINE=MEMORY并指定INDEX），这时不如用派生表 + 强制索引提示/*+ USE_INDEX(...) */ - 别在存储过程中无条件反复
DROP + CREATE临时表，锁和解析开销会累积
嵌套深本身不致命，致命的是每层都扫全表、每行都触发子查询、或者优化器完全放弃估算。拆解动作必须绑定具体执行计划和数据分布，而不是按层数机械切分。
