视图嵌套超过3层必然导致性能失控，因优化器放弃代价估算、条件下推失效、执行计划随机漂移；EXPLAIN可能显示正常但实际未下推过滤条件，估算行数爆炸、频繁物化、计划不一致即为典型症状。
视图嵌套超过3层，性能大概率已失控，不是“可能慢”，而是“必然不可控”——优化器放弃代价估算、条件下推失效、执行计划随机漂移，这是结构性问题，不是加个索引能救的。
为什么嵌套视图会让EXPLAIN看起来“没问题”但实际极慢
你跑 EXPLAIN ANALYZE 看到的可能是“Seq Scan on orders”，但没告诉你这行扫描是发生在最内层视图 v_region_map 还是外层 v_orders_summary；更关键的是，如果外层加了 WHERE country = 'CN'，而执行计划里这条件根本没下推到 regions 表的扫描节点，说明优化器已放弃重写整个嵌套链。常见现象包括：
- 估算行数从 100 跳到 1000000（爆炸式增长）
- 出现未预期的
Materialize节点，且耗时占总时间 70%+ - 同一查询在不同时间生成完全不同的执行计划（比如有时走 Nested Loop，有时变 Hash Join）
用CTE替代嵌套视图时，哪些写法会适得其反
CTE 不是万能扁平化工具，错误用法反而加重负担。PostgreSQL 默认可能将 CTE 当作物化步骤强制执行，而原视图嵌套反而支持条件下推。必须避开这些坑：
- 在 CTE 定义里写
SELECT *—— 多余列会阻止外层 WHERE 下推到基表 - 让多个 CTE 交叉引用（比如
A依赖B，B又依赖A）—— 打破线性执行顺序，优化器可能退化为全物化 - 在中间 CTE 里加
ORDER BY或LIMIT—— 触发排序或截断，后续无法复用结果集 - MySQL 8.0.23+ 之前没
MATERIALIZED提示，盲目用 CTE 替代视图，可能让原本可内联的逻辑被强制物化
什么时候该建物化视图，而不是继续扁平化
物化不是“加速单次查询”的银弹，它解决的是重复消费 + 低更新频次场景。判断标准很具体：
- 该中间结果在 24 小时内被 ≥5 个不同业务查询调用，且每次过滤字段差异大（比如一个查
WHERE status = 'paid'，另一个查WHERE created_at > '2026-04-01'） - 其基表数据变更频率 ≤ 每小时 1 次，且物化后能减少 ≥70% 的逻辑读（用
EXPLAIN (ANALYZE, BUFFERS)对比验证） - 你愿意承担调度成本：SQL Server 需
CREATE MATERIALIZED VIEW+ 定时REFRESH；PostgreSQL 用CREATE MATERIALIZED VIEW+REFRESH MATERIALIZED VIEW CONCURRENTLY；MySQL 得靠临时表 + 调度任务
嵌套超3层后，依赖关系基本不可信，必须人工验证
SQL Server 的 sp_depends 已弃用，对 v_a → v_b → v_c → v_d 这种链式引用直接返回空；pg_depend 在 PostgreSQL 中也难以准确追踪跨多层视图的列级依赖。这意味着：
- 改底层表字段名，可能只报错在最外层视图，但真实断裂点在第二层
- 删掉一个中间视图，你以为只是少一层，结果发现五个报表同时崩——因为它们都隐式依赖该视图输出的某列别名
- 唯一可靠方式是：导出所有视图定义，用正则匹配
FROM\s+([a-z_]+)和JOIN\s+([a-z_]+)，手工画依赖图；或用pg_get_viewdef()逐层展开，确认每一层真正访问了哪些基表和列
嵌套视图真正的复杂点不在语法或写法，而在“谁在用它、怎么用、改了会影响谁”——这部分永远没法靠 EXPLAIN 或自动化工具覆盖，必须有人盯着。
