嵌套超3层会导致优化器结构性失效，必须拆解：通过EstimatedRows与ActualRows差距超3个数量级、高频Materialize/Spool节点耗时占比超70%、physical reads暴增百万级来确认；CTE非语法糖，错误用法（如SELECT *、交叉引用、ORDER BY/LIMIT）会强制物化；中间结果超1万行且需多次JOIN时应优先建带索引的临时表；半连接类嵌套应重写为JOIN并建立复合索引；分库分表下IN子查询须改JOIN且ON含分片键；真正卡点在于人工验证每层行数分布与索引命中。
嵌套超过3层的查询，优化器基本放弃代价估算和条件下推——这不是配置能调的，是结构性失效。必须拆解，不能硬扛。
EXPLAIN里没报错但实际极慢，怎么确认是嵌套导致的？
别只看执行计划有没有ERROR或WARNING，重点盯三处：
-
EstimatedRows和ActualRows差距超3个数量级（比如预估120行，实际扫了150万行），就是条件下推失败的铁证 - 出现高频
Materialize（PostgreSQL）或Table Spool（SQL Server）节点，且耗时占总时间70%+，说明中间结果被反复物化 -
physical reads暴增（用EXPLAIN ANALYZE BUFFERS或SET STATISTICS IO ON对比），从几千跳到百万级，基本可锁定嵌套失控
用CTE替代嵌套视图，为什么有时更慢？
CTE不是语法糖，它改写了优化器的决策路径。错误用法会强制物化、阻断下推：
- 在CTE里写
SELECT *：多余列阻止外层WHERE下推到底层基表，拖慢I/O和page fault - 多个CTE交叉引用（A依赖B、B又依赖A）：优化器退化为全物化，失去线性执行优势
- 中间CTE加
ORDER BY或LIMIT：触发无谓排序或截断，后续无法复用结果集 - MySQL 8.0.23前默认不物化CTE，若被引用两次，可能重复执行过滤逻辑；PostgreSQL则默认物化，但需加
MATERIALIZED显式控制
什么时候该建临时表而不是死磕CTE？
当CTE表现不稳定、或中间结果 >1万行且需多次JOIN/过滤时，临时表更可控：
- 建完
CREATE TEMPORARY TABLE tmp AS SELECT ...后，立刻执行ALTER TABLE tmp ADD INDEX idx_user_id (user_id)——没索引的临时表JOIN就是全表扫描 - MySQL临时表不支持全文索引，PostgreSQL临时表索引只在当前会话有效，别漏掉这步
- 临时表名别用
tmp_*这类泛化前缀，ORM可能生成同名表导致冲突 - 如果子查询本身含聚合或复杂过滤，临时表比CTE更容易让优化器获得准确行数统计
JOIN能替代的嵌套，优先重写而非拆分
很多所谓“嵌套”，本质是半连接或存在性判断，硬写成子查询反而触发 DEPENDENT SUBQUERY：
-
WHERE id IN (SELECT user_id FROM logs WHERE status = 'success')→ 改成INNER JOIN logs ON t.id = logs.user_id AND logs.status = 'success'，并确保logs(status, user_id)有复合索引 -
NOT IN遇到NULL直接丢整行，且无法走哈希连接；优先换NOT EXISTS，或用LEFT JOIN ... WHERE inner.id IS NULL - 分库分表环境下，
IN子查询几乎必然广播；必须改JOIN，且ON条件含分片键，否则仍是跨库拉取
真正卡点不在“怎么写”，而在“哪一层开始拆”。嵌套超3层后，依赖链已不可信，必须人工验证每一层输出的行数分布和索引命中情况——靠EXPLAIN猜，不如直接 EXPLAIN ANALYZE 跑一遍最内层子查询看真实耗时。
