视图嵌套超过3层必然导致性能失控，因优化器主动放弃代价估算、谓词无法下推、执行计划随机漂移；确认依据是：外层where未下推至基表扫描节点、estimatedrows与actualrows偏差超3个数量级、materialize/table spool节点耗时占比超70%。

视图嵌套超过3层，性能不是“可能慢”，而是必然失控——优化器主动放弃代价估算、谓词无法下推、执行计划随机漂移。这不是配置或索引能调的，是结构性失效。

EXPLAIN显示正常但实际极慢，怎么确认是嵌套惹的祸？

别只看有没有警告，盯住三类铁证：

• WHERE country = 'CN'写在外层，但执行计划里regions表的扫描节点没出现这个过滤条件——说明条件下推彻底失败
• EstimatedRows和ActualRows差3个数量级以上（比如预估100行，实际扫了80万行）
• PostgreSQL里高频出现Materialize节点且耗时占比＞70%；SQL Server里大量Table Spool (Eager Spool)

为什么MySQL 5.7及以前的嵌套视图特别危险？

它默认不支持view merging，哪怕你只查v_orders_summary的一个字段，也会先完整执行所有嵌套定义再过滤。相当于每次调用都在做全量计算。

• 你加WHERE id = 123，它不会下推到最内层基表，而是先算出百万行结果，再从中挑1行
• 视图里用了SELECT *，后续列序变化（如基表新增字段）会导致字段错位，连结果都错
• 权限检查发生在调用时，不是创建时——用户没orders表的SELECT权，查视图直接报ERROR 1142 (42000)

CTE替代嵌套视图，为什么有时更慢？

WITH不是语法糖，它改写了优化器的决策路径。错误写法会强制物化、阻断下推：

• 在CTE里写SELECT *：多余列阻止外层WHERE下推到底层基表，拖慢I/O和page fault
• 多个CTE交叉引用（如A AS (SELECT * FROM B), B AS (SELECT * FROM A)）：优化器退化为全物化，失去线性优势
• 中间CTE加ORDER BY或LIMIT：触发无谓排序或截断，后续JOIN只能重算
• MySQL 8.0.23前默认不物化CTE，若被引用两次，可能重复执行同一过滤逻辑

真正卡点不在语法，而在人工验证每层行数分布与索引命中

嵌套超3层后，依赖关系基本不可信：sp_depends在SQL Server已弃用，pg_depend在PostgreSQL中也难以准确追踪v_a → v_b → v_c → v_d这种链式引用。你必须手动跑EXPLAIN ANALYZE，逐层看rows是否爆炸、Index Cond是否生效、Buffers是否暴增百万级——这些才是决定要不要拆、往哪拆的关键信号。