嵌套视图导致执行计划失控、索引失效与调试成本剧增。优化器将其内联展开为巨型扁平sql，丢失语义边界，使谓词无法下推、表被重复扫描、权限检查复杂化，且错误定位困难。
视图本身不是问题，问题出在嵌套视图的不可控展开 + 隐式性能退化上。它会让原本可控的查询逻辑，在运行时变成“黑盒爆炸”。
视图嵌套导致执行计划失控
数据库优化器对嵌套视图没有深度感知能力，它会把所有视图定义一层层内联展开（inline expansion），最终生成一个巨型、扁平化的 SQL。这个过程丢失了原始视图的语义边界和中间结果约束。-
CREATE VIEW v1 AS SELECT * FROM orders WHERE status = 'paid' -
CREATE VIEW v2 AS SELECT * FROM v1 JOIN users u ON v1.user_id = u.id -
CREATE VIEW v3 AS SELECT COUNT(*) FROM v2 WHERE u.region = 'CN'
当你查 v3，优化器实际执行的是：SELECT COUNT(<em>) FROM (SELECT </em> FROM orders WHERE status = 'paid') t1 JOIN users u ON t1.user_id = u.id WHERE u.region = 'CN'
但关键在于：优化器可能忽略外层 WHERE u.region = 'CN' 对内层 orders 的提前过滤价值，仍先扫描全部 'paid' 订单（哪怕只有 0.1% 属于 CN），再 join 再过滤。
常见错误现象：
- 图形执行计划里出现多个
Seq Scan或Clustered Index Scan，且估算行数与实际行数偏差 10 倍以上 -
EXPLAIN ANALYZE显示某嵌套节点的Actual Rows是百万级，但上游只传几十行进来 - 同一物理表在展开后被多次扫描（尤其在多层 LEFT JOIN 视图中）
索引失效在嵌套中被放大
单层视图里用UPPER(email) 可能只是让一个字段走不了索引；嵌套视图里，这种失效会传导、叠加，甚至触发隐式转换链。
- 视图 A 中：
ON UPPER(o.email) = UPPER(u.email)→ 两边函数化，索引失效 - 视图 B 基于 A 再
JOIN addresses a ON a.user_id = u.id，而u.id实际是视图 A 中从orders和users联合推导出的表达式 - 最终优化器根本无法识别
a.user_id对应的底层索引列，强制全扫addresses
容易踩的坑：
- 把视图当“函数”用：以为
SELECT * FROM v_deep_nested WHERE dt > '2024-01-01'会自动下推条件，实际可能完全不生效 - 在嵌套视图里混用
UNION ALL或子查询，进一步干扰优化器对行数的估算 - 使用
SCHEMABINDING锁定结构，反而阻碍优化器做等价改写（如谓词下推）
权限与调试成本随嵌套指数上升
每加一层视图，就多一层访问控制依赖、多一层元数据解析开销、多一层错误定位难度。- 权限检查不是一次性完成的：查
v3时，数据库要验证你对v2、v1、orders、users、addresses全部有SELECT权，任一缺失就报错，错误信息却只说“permission denied for view v3” -
pg_stat_statement或sys.dm_exec_query_stats统计的是最终展开后的 SQL，你根本看不出哪段来自哪层视图 - 修改某字段别名？可能要从最底层表开始逐层检查所有依赖视图是否用了该别名，否则运行时报
column xxx does not exist
真正难处理的，从来不是“能不能写出来”，而是“出问题时，你根本不知道该去哪层查”。嵌套视图把本该线性的调试路径，变成了需要手动展开、重写、再比对的逆向工程。
