视图嵌套超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，就失去反连接语义，变成先笛卡尔积再过滤
嵌套层级本身不是数字游戏，而是优化器能力的分水岭。超过三层后，你面对的不再是“怎么调优”，而是“能否信任执行计划”——这点最容易被忽略，也最致命。
