视图嵌套超3层易丢失依赖关系，需手动建元数据表或拆分为物化中间表；sql server有32层硬限制，应提取共用逻辑为函数或推至远程实例。
视图嵌套超过3层就容易查不出依赖关系
PostgreSQL 的 pg_depend 和 SQL Server 的 sys.dm_exec_describe_first_result_set 在视图嵌套过深时，会丢失中间层的列级依赖；MySQL 甚至不暴露视图依赖链。不是工具不行，是它根本没被设计来追踪「A→B→C→D→E」这种链式引用。
- 用
pg_views（PostgreSQL）或sys.views（SQL Server）只能看到直接定义，看不到谁在用它 -
sp_depends在 SQL Server 中已弃用，且对嵌套视图返回空结果 - MySQL 8.0 的
INFORMATION_SCHEMA.VIEWS不记录依赖，只能靠正则扒VIEW_DEFINITION字段
真正能摸清链路的，只有手动加注释 + 建立轻量元数据表：建一张 view_dependency，字段为 view_name、depends_on、level，每次改视图就跑脚本更新——别指望自动发现，它不现实。
把 UNION ALL 拆成物化中间表能砍掉两层嵌套
常见模式是：报表视图 → 聚合视图 → 清洗视图 → 原始表。其中清洗视图常含 UNION ALL 多源合并，导致上层必须重算全部分支。把它抽成带索引的中间表，既断开依赖链，又避免重复扫描。
- 中间表命名加前缀如
mvw_cleaned_orders，明确区别于逻辑视图 - 用
CREATE TABLE AS SELECT（PostgreSQL/MySQL）或SELECT INTO（SQL Server）生成，比视图快且可建索引 - 调度任务里加一步
REFRESH MATERIALIZED VIEW或TRUNCATE + INSERT，别让它 stale
注意：SQL Server 不支持原生物化视图（除非用索引视图），得用表+触发器或作业定时刷；MySQL 没物化视图，老老实实建表。
用 CTE 替代多层视图时小心执行计划退化
把 v_report → v_summary → v_base 改成单个视图内写 WITH base AS (...), summary AS (...), report AS (...)，看起来扁平了，但 PostgreSQL 可能将 CTE 当作物化步骤强制执行，而原本的视图嵌套反而能下推过滤条件。
- 加
/*+ MATERIALIZE */（Oracle）或NOT MATERIALIZED（PostgreSQL 12+）显式控制行为 - 对比
EXPLAIN (ANALYZE, BUFFERS)输出，重点看Actual Rows是否暴增 - 如果 CTE 里有
GROUP BY或DISTINCT，大概率会被物化，此时不如保留底层视图并加过滤参数
CTE 扁平化是语法糖，不是性能优化手段——它解决的是可读性，不是执行路径。
SQL Server 视图嵌套报错 “View or function 'X' has more than 32 nesting levels”
这是硬限制，到 32 层就直接报错 Msg 319，连编译都过不去。不能靠“再少一层”侥幸，必须结构性拆解。
- 检查是否无意循环引用：用
sys.dm_exec_describe_first_result_set(N'SELECT * FROM X')看返回列，若报错含depends on itself就是循环 - 把高频共用逻辑（比如客户状态计算）提取为标量函数
ufn_customer_status()，函数不计入嵌套层级 - 用
OPENQUERY或链接服务器把部分逻辑推到另一实例——跨实例不算本地嵌套
真正难处理的不是层数本身，而是改一个底层视图要测 5 个上游报表。所以每次新增视图前，先问一句：这个逻辑，能不能塞进已有视图的 CASE WHEN 里？
