视图嵌套超3层必然导致执行计划失控，表现为预估/实际行数偏差超3个数量级、高频Materialize节点耗时超70%、physical reads暴增，此时加索引或调参无效，必须拆解为带索引的临时表或重写为JOIN。
视图嵌套超过3层时，查询延迟不是“可能变高”，而是执行计划已失控——优化器放弃代价估算、外层WHERE无法下推、中间结果频繁物化，这是结构性瓶颈，不是加索引或调参数能绕开的。
怎么看是不是嵌套导致的延迟？
别只盯着“慢”，重点验证三处真实信号：
-
EXPLAIN ANALYZE（PostgreSQL）或SET STATISTICS XML ON（SQL Server）里，EstimatedRows和ActualRows差3个数量级以上（比如预估120行，实际扫了150万行） - 执行计划中出现高频
Materialize（PG）、Table Spool（SQL Server）节点，且耗时占比超70% -
physical reads暴增（如从1200跳到2.4M），说明大量磁盘I/O被无效中间结果触发
为什么用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表现不稳定、或中间结果集行数稳定超1万、且需多次JOIN/过滤时，临时表比CTE更可控：
- 建完
CREATE TEMPORARY TABLE tmp AS SELECT ...后，立刻执行ALTER TABLE tmp ADD INDEX idx_user_id (user_id)——没索引的临时表JOIN就是全表扫描 - MySQL临时表不支持全文索引；PostgreSQL临时表索引只在当前会话有效，漏掉这步等于白建
- 如果子查询本身含聚合或复杂过滤（如
GROUP BY user_id, DATE(created_at)），临时表能让优化器获得准确行数统计，避免计划漂移
哪些嵌套必须重写为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' -
WHERE NOT EXISTS (SELECT 1 FROM payments p WHERE p.order_id = o.id)→ 改成LEFT JOIN payments p ON p.order_id = o.id WHERE p.order_id IS NULL - 重写后，给
logs.user_id和logs.status建复合索引idx_logs_user_status，让JOIN走Index Seek而非Nested Loop
真正卡点不在语法怎么写，而在于人工逐层验证每张基表的ActualRows分布、索引命中率、以及WHERE条件是否真的落在了最内层扫描节点上——只要有一层没下推，整个链就白优化。
