SQL视图嵌套超过2层就大概率失控，因优化器放弃条件下推、估算误差叠加，导致Materialize/Spool节点占比超60%、执行计划随机漂移、估算行数爆炸式增长。
能嵌套，但超过2层就大概率失控
SQL标准允许视图引用其他视图，语法上完全合法。但实际执行时，数据库优化器对嵌套的容忍度极低：PostgreSQL 和 SQL Server 在 3 层嵌套后常放弃条件下推；MySQL 5.7 根本不支持视图合并，哪怕只嵌套 2 层，WHERE 条件也几乎不可能下推到基表。
嵌套视图性能崩坏的典型信号
别等用户投诉才查，这几个现象一出现，说明嵌套已开始反噬：
-
EXPLAIN ANALYZE显示Materialize或Table Spool节点耗时占比超 60% - 同一查询两次执行，计划完全不同（比如一次用
Hash Join，另一次退化为Nested Loop） - 估算行数从几百跳到百万级，而基表实际只有几千行
- 外层加了
WHERE id = 123，执行计划里却仍是全表扫描Seq Scan on orders
为什么“看起来正常”的嵌套会慢得离谱
根本问题不在语法，而在优化器“看不透”多层包装：
- 数据库不跟踪语义依赖，只做静态列名校验——
v_kpi引用v_base，v_base字段重命名后，v_kpi不报错，直到查询时才抛Column not found - 每多一层嵌套，就多一次逻辑重写和估算误差叠加；三层之后，PostgreSQL 可能直接禁用视图展开，SQL Server 容易生成嵌套循环，MySQL 退化成多次临时表拼接
-
COALESCE(col, 'default')、OFFSET、窗口函数等不可下推表达式，只要出现在任一层视图定义里，整条链的条件下推就会中止
真要嵌套，必须守住的硬边界
不是不能用，而是得用得极其克制：
- 嵌套深度严格 ≤ 2 层：只允许「基础聚合视图 → 业务指标视图」，禁止
v_base → v_agg → v_report → v_dashboard这类四层链 - 中间层视图第一行加注释：
-- DEPENDS ON: v_sales_base (columns: dept_id, order_amt) - MySQL 必须显式声明
ALGORITHM=MERGE；SQL Server 视图创建时加WITH SCHEMABINDING，否则优化器大概率绕过合并 - 所有视图定义里禁用
SELECT *、ORDER BY、DISTINCT、GROUP BY——这些是条件下推的断点
真正难处理的从来不是语法嵌套，而是当你发现 v_kpi 返回结果错位，却要翻三层视图定义、比对字段映射、验证每一层的过滤条件是否一致——这种维护成本，远高于一开始就把逻辑写进 CTE 或应用层。
