嵌套视图超过三层必然导致依赖失控与性能劣化——优化器放弃谓词下推、执行计划随机漂移、错误定位困难；mysql/pg/sql server虽语法允许任意嵌套，但实际运维中必须拆解为显式字段视图或物化中间表，并禁用select *。
嵌套视图的创建语法本身很简单，但依赖层级失控才是真问题
MySQL、PostgreSQL、SQL Server 都允许在 CREATE VIEW 的 SELECT 语句中直接引用已存在的视图，语法上没有限制层数。比如：CREATE VIEW v3 AS SELECT * FROM v2 JOIN v1 ON ... 完全合法。但问题不在于“能不能写”，而在于“写了之后谁来维护、谁来查错、谁来优化”。
常见错误现象包括：
- 修改
v1的字段名后，v3查询报Unknown column 'x' in 'field list'，但错误位置指向v3定义，实际崩在v1 - 测试环境漏建
v2，应用查v3返回空结果，日志里只有一句SELECT * FROM v3，无任何提示 - 执行计划里出现多层
DERIVED（MySQL）或MATERIALIZED（PostgreSQL），I/O 翻倍，响应从 50ms 涨到 2s
三层以上嵌套视图必须拆掉，别信“逻辑清晰”这种幻觉
所谓“v_kpi → v_region → v_base”这种分层，在数据库眼里就是一次性展开成一个大 SQL：所有 JOIN、WHERE、SELECT * 全部拍平。优化器既不能下推过滤条件，也很难重排 JOIN 顺序，更没法对中间结果复用索引。
真正该做的，是把“稳定结构”和“动态逻辑”物理隔离：
-
v_base只做最基础的表关联与列映射，例如SELECT o.order_id, u.user_level, p.category FROM orders o JOIN users u ON o.user_id = u.id JOIN products p ON o.product_id = p.id，且必须显式列出字段，禁用* - 所有时间范围、地域筛选、状态过滤等，全部交给外层查询，如
SELECT order_id, user_level FROM v_base WHERE order_date >= '2026-07-01' AND category = 'electronics' - 如果确实需要参数化（比如按部门查销售），改用表值函数：
CREATE FUNCTION get_sales_by_dept(dept_id INT) RETURNS TABLE(...)（PostgreSQL/SQL Server），但注意它无法被所有优化器下推，得实测执行计划
SQL Server 中 CTE 不是嵌套视图的替代方案
有人想用 WITH a AS (...), b AS (SELECT * FROM a ...), c AS (SELECT * FROM b ...) 来模拟“可读的嵌套”，这没错，但它和视图完全不是一回事：CTE 是语句级临时定义，不能跨查询复用，也不能授予权限，更不能被其他视图引用。它只是把一个长查询写得清楚点，不是解耦手段。
关键区别：
- CTE 名称只在当前
SELECT/INSERT/UPDATE语句中有效；视图名全局可见、可授权、可被其他视图引用 - SQL Server 不支持真正的嵌套 CTE（即在一个 CTE 定义体内再写
WITH），否则报Incorrect syntax near 'WITH' - CTE 如果引用了大表且未加过滤，照样触发全表扫描——它不改变数据访问路径，只改变写法
检查现有嵌套依赖的最简方法
别靠人肉翻 DDL。用系统视图快速定位风险点：
- MySQL：查
information_schema.VIEW_TABLE_USAGE和information_schema.VIEWS，连表找出哪些视图引用了其他视图，再统计引用深度 - PostgreSQL：运行
SELECT * FROM pg_depend WHERE refclassid = 'pg_class'::regclass AND classid = 'pg_class'::regclass AND deptype = 'n';，结合pg_views追踪依赖链 - SQL Server：用
sys.dm_exec_describe_first_result_set(N'SELECT * FROM your_view')查返回列来源，再手动逆向查定义；或者用sp_depends your_view（虽已弃用但尚可用）
超过两层的依赖链，基本意味着每次改底层字段都要手动验证三层，而且没人敢动——这才是最危险的状态。
