视图嵌套超过3层必然导致性能不可控，因优化器放弃代价估算、条件下推失效、执行计划随机漂移；explain看似正常实则未下推过滤条件，估算行数爆炸、频繁物化、计划不一致即为典型症状。
视图嵌套超过3层，性能不是“可能慢”，而是“必然不可控”——优化器会放弃代价估算、条件下推失效、执行计划随机漂移，加索引或调参数都救不回来。
为什么EXPLAIN看起来正常但查询慢得离谱
你看到的 EXPLAIN ANALYZE 输出里可能是 Seq Scan on orders，但它没告诉你这扫描发生在哪一层：是直接扫基表，还是在 v_region_map 里被物化后又扫一遍？更关键的是，外层加了 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—— 触发排序或截断，后续无法复用结果集
正确写法示例（PostgreSQL/SQL Server）：
WITH region_map AS ( SELECT region_id, country FROM regions WHERE active = true ), customers_active AS ( SELECT c.id, c.name, r.country FROM customers c JOIN region_map r ON c.region_id = r.region_id ), orders_summary AS ( SELECT o.order_id, ca.country, COUNT(*) cnt FROM orders o JOIN customers_active ca ON o.customer_id = ca.id GROUP BY o.order_id, ca.country ) SELECT * FROM orders_summary WHERE country = 'CN';
什么时候该建物化视图，而不是硬扁平
物化不是“加速单次查询”的银弹，它解决的是重复消费 + 低更新频次场景。判断标准很具体：
- 该中间结果在 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得靠临时表 + 调度任务
SQL Server 报错 “View has more than 32 nesting levels” 怎么办
这不是性能问题，是硬限制：到第32层就直接编译失败，报错 Msg 319。此时任何优化器行为都还没开始，只能重构。
- 立刻停用
sp_depends—— 它已弃用，对嵌套视图返回空结果 - 手动梳理依赖链：建一张轻量元数据表
view_dependency，字段为view_name、depends_on、level，每次改视图就跑脚本更新 - 把清洗类逻辑（如含
UNION ALL的多源合并）抽成带索引的中间表，命名如mvw_cleaned_orders，既断开依赖链，又避免重复扫描
真正难处理的不是“怎么扁平”，而是嵌套超3层后，依赖关系基本不可信——你改了 v_b，根本没法确定 v_d 是否受影响，必须人工验证每一层的字段映射和过滤逻辑。
