视图嵌套超3层必然导致优化器放弃精确代价估算，引发条件下推失效、执行计划漂移、全表扫描等结构性性能问题。

嵌套视图让优化器“放弃思考”

视图嵌套超过 3 层，PostgreSQL、SQL Server 和 MySQL 的查询优化器大概率会停止精确代价估算，转而采用保守甚至随机的执行策略。这不是配置问题，而是设计限制——优化器内部对重写深度有硬性阈值。一旦触发，WHERE 条件无法下推、JOIN 顺序错乱、本该走索引的扫描变成全表扫，都是必然结果。

• EXPLAIN 显示 “Seq Scan on orders”，但没告诉你这扫描发生在哪一层；外层加了 WHERE country = 'CN'，执行计划里却完全没出现在基表节点上，说明条件下推已失效
• 估算行数从 100 爆涨到 1000000，是典型优化器失控信号
• 同一查询两次运行，一次走 Nested Loop，一次变 Hash Join，执行计划漂移证明优化器已退化

SELECT * 在视图里等于主动锁死优化路径

视图定义中只要出现 SELECT *，就等于告诉数据库：“不管外层要什么，你先给我把所有字段全拉出来再说”。尤其在 PostgreSQL 和 SQL Server 中，这极易触发物化（Materialize），哪怕外层只查 id, name，也会先读取并暂存 TEXT、JSON 或大字段，再裁剪——内存暴涨、缓冲区压力骤增。

• 外层加 LIMIT 10，但视图里含 ORDER BY score DESC → PostgreSQL 全量排序后截断，MySQL 可能直接忽略 LIMIT
• 想按子查询结果排序，比如 ORDER BY (SELECT MAX(ts) FROM events WHERE ref_id = u.id) → 强制逐行求值，无法用索引加速
• 视图返回冗余字段后 JOIN 其他表 → 哈希表构建变慢，JOIN 性能断崖下跌

三层以上嵌套时，依赖关系基本不可信

SQL Server 的 sp_depends 已弃用，对 v_a → v_b → v_c → v_d 这种链式引用直接返回空；PostgreSQL 的 pg_depend 也难以准确追踪跨层列来源。你改了最内层视图的某个字段类型，可能在外层查询报错前，根本没人知道它被哪几个报表在用。

• 手动展开必须用 pg_get_viewdef()（PostgreSQL）或 sp_helptext（SQL Server），但拼出的等价 SQL 加上 WHERE 后，执行计划常和原视图查询完全不同
• MySQL 5.7+ 默认用 TEMPTABLE 算法处理含子查询的视图，意味着外层 WHERE 根本没机会参与子查询的谓词下推
• 权限、架构名、隐式类型转换等问题，全在运行时才暴露，测试环境很难覆盖

EXISTS 嵌套 + 视图嵌套 = 性能雪崩

当视图里还嵌了 EXISTS 子查询，每层嵌套都会放大执行次数：外层扫一行，中间层重跑一次；中间层再扫一行，最内层又重跑一次。实际复杂度不是 O(n)，而是 O(n × m × k)，尤其某层缺失索引（type=ALL）或用了函数（如 DATE(create_time)），性能直接断崖下跌。

• EXPLAIN FORMAT=TREE 显示多层 Nested Loop，且内层 rows 列数值随外层放大，就是典型症状
• CPU 持续 90%+，不是并发高，而是单查询就在反复做相同计算
• 用 LEFT JOIN ... ON ... AND ... 替代 NOT EXISTS 时，ON 子句必须包含全部过滤条件；若把 status = 'paid' 放到 WHERE，就失去反连接语义，变成先笛卡尔积再过滤

嵌套层级本身不是数字游戏，而是优化器能力的分水岭。超过三层后，你面对的不再是“怎么调优”，而是“能否信任执行计划”——这点最容易被忽略，也最致命。