嵌套超过3层时，主流数据库优化器基本放弃优化：PostgreSQL、SQL Server和MySQL 8.0+均显著降低重写能力，WHERE条件无法下推，执行计划不稳定，基数估算严重失真，解析开销指数增长，CTE误用反而加重负担，应优先考虑物化视图而非盲目扁平化。
嵌套超过3层，优化器基本放弃治疗
PostgreSQL、SQL Server 和 MySQL 8.0+ 都会在视图嵌套达到3层后显著降低重写能力。不是“可能不优化”，而是明确放弃代价估算——EXPLAIN 显示的执行计划里，Filter 节点常卡在外层，WHERE 条件根本没下推到基表扫描节点。你看到 Seq Scan on orders，但不知道这行扫描实际发生在第几层视图内部；更糟的是，同一查询在不同时间可能生成 Nested Loop 或 Hash Join，因为优化器已无法稳定评估中间结果集大小。
- 估算行数从
120爆涨到1200000是典型信号 - 出现未预期的
Materialize节点，且占总耗时 >70% -
pg_depend在 PostgreSQL 中对v_a → v_b → v_c → v_d这类链式依赖基本不可靠，sp_depends在 SQL Server 中已弃用
为什么解析器压力会指数级上升
每多一层嵌套，查询解析器就要多做一次逻辑展开 + 别名绑定 + 列映射。MySQL 5.7 对 SELECT * FROM (SELECT * FROM (SELECT ...)) 的解析开销是非线性的；Oracle 的 WITH 子句默认深度限制为 32，但每增加一层，语法树节点数翻倍，内存占用和解析时间呈平方增长。这不是 CPU 不够，是解析阶段就卡在语义等价判断上——比如两个视图都叫 id，但来源不同表，优化器必须逐层回溯字段 lineage，而嵌套越深，lineage 越模糊。
- 嵌套视图中只要有一处
SELECT *，外层WHERE就大概率无法下推 - 含
UNION或聚合的视图，会被优化器标记为“不可内联”，强制物化，哪怕只被引用一次 - SQL Server 中
SCHEMABINDING能缓解部分问题，但无法修复嵌套导致的基数误估
CTE 替代嵌套视图时最常踩的坑
CTE 不是视图嵌套的“平替”，错误用法反而加重负担。PostgreSQL 默认把 CTE 当作物化步骤（MATERIALIZED），而原生视图有时还能内联；MySQL 8.0+ 默认用 NO_MERGE，但一旦你在 CTE 定义里加了 ORDER BY 或 LIMIT，就会意外禁用物化，让原本该复用的结果集被重复计算。
- 别写：
WITH v AS (SELECT * FROM orders WHERE status = 'paid') SELECT * FROM v JOIN users ON v.user_id = users.id——SELECT *阻止条件后推 - 避免交叉引用：
cte_a AS (SELECT * FROM cte_b)+cte_b AS (SELECT * FROM cte_a)会让优化器直接退化为全物化 - MySQL 8.0.23 之前没有
MATERIALIZED提示，盲目用 CTE 替代可内联的视图，等于主动放弃优化机会
真正该扁平化的，是调用链而非单个视图
不要盯着“这个视图能不能拆”，而要看“谁在调用它、怎么调用”。一个被 5 个不同业务查询反复调用的中间结果，如果每次过滤字段差异大（WHERE status = 'paid' vs WHERE created_at > '2026-04-01'），且基表变更 ≤ 每小时 1 次，那它就该建 MATERIALIZED VIEW，而不是继续压平到 SQL 里。否则你花半天重写视图，上线后发现应用层又套了一层 VIEW 调用，等于白干。
复杂点从来不在语法层面，而在依赖路径是否可验证、执行计划是否可预期。嵌套超 3 层后，连 pg_get_viewdef() 返回的定义都可能漏掉某一层的 WHERE 条件，这时候靠人肉 review 已经不可靠了。
