视图嵌套超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条件是否真的落在了最内层扫描节点上——只要有一层没下推，整个链就白优化。