视图中嵌套子查询性能差的根本原因是视图展开后子查询与外层逻辑耦合，导致优化器丧失独立优化空间，尤其相关子查询会被反复执行且过滤条件难以下推。
视图中嵌套子查询性能差，根本原因不是“视图+子查询”这个组合本身有问题，而是数据库在展开视图时，把子查询和外层逻辑耦合进一个大执行计划里，导致优化器失去独立优化空间——尤其当子查询是相关子查询时，它会被反复执行，甚至无法下推过滤条件。
视图展开后子查询变成 DEPENDENT SUBQUERY
SQL Server 和 MySQL 在展开视图时，不会预先物化子查询结果；PostgreSQL 虽支持 CTE 自动物化，但视图仍按标准语义展开。一旦子查询引用了视图外部的列（比如 WHERE o.user_id = u.id），优化器就标记为 DEPENDENT SUBQUERY 或等价的嵌套循环节点。
- 检查方法：对视图查询执行
EXPLAIN ANALYZE（PostgreSQL）或SET STATISTICS XML ON（SQL Server），看执行计划中是否出现“Nested Loops”内嵌子查询、或“Compute Scalar”反复调用标量子查询 - 典型现象：外层主表扫描 10 万行 → 子查询被触发 10 万次 → 即使子查询本身毫秒级，总耗时也飙升到分钟级
- 注意：视图定义里写
SELECT (SELECT COUNT(*) FROM orders WHERE user_id = users.id)，和直接写这条 SQL 效果一致，但更容易被忽略——因为“它只是个视图”
索引失效在视图展开后更隐蔽
单独测试子查询可能走索引，但嵌入视图后，因字段类型隐式转换、JOIN 顺序错乱或谓词下推失败，索引突然失效。
- 常见诱因：
users.id是INT，而视图里 JOIN 的orders.user_id是VARCHAR→ 视图展开后自动加CONVERT，索引失效 - 另一个坑：
WHERE status = 'active'在子查询里，但视图外层又加了AND created_at > '2024-01-01'，优化器可能放弃下推，导致子查询全表扫描后再过滤 - 验证动作：把视图定义里的子查询单独拎出来，加上和外层完全相同的
WHERE条件，再EXPLAIN对比——如果单独跑快、嵌入视图后变慢，基本就是展开逻辑破坏了索引利用
嵌套视图 + 子查询 = 执行计划爆炸
视图 A 引用视图 B，B 里又有子查询，这种结构会让优化器生成冗余中间结果，甚至重复计算同一子查询多次。
- 例如：视图
v_user_summary包含子查询统计订单数，视图v_active_users又基于它加过滤；最终查询SELECT * FROM v_active_users展开后，订单统计子查询可能被实例化两次（一次算总数、一次算活跃用户数） - PostgreSQL 的
EXPLAIN中若看到多个Materialize节点或高占比的Shared Read，大概率是这类问题 - 临时缓解：用
WITH提前物化关键子查询结果，比如WITH order_counts AS (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) SELECT ... FROM users u JOIN order_counts o ON u.id = o.user_id，绕过视图展开
什么情况下必须放弃视图改用其他方案
不是所有带子查询的逻辑都适合塞进视图。当出现以下任一情况，硬套视图只会让性能和维护性双崩：
- 需要传参过滤（如按日期范围动态统计）→ 改用内联表值函数（
CREATE FUNCTION dbo.fn_orders_by_date(@from DATE)），SQL Server 可参数化，PostgreSQL 可用RETURN QUERY EXECUTE - 子查询结果稳定、更新不频繁（如地区维度统计）→ 直接建物化视图（
MATERIALIZED VIEWin PostgreSQL）或定时刷新的汇总表 - 子查询涉及窗口函数或复杂聚合，且外层常取
LIMIT→ 视图里套ORDER BY ... LIMIT基本无效（MySQL 5.7/8.0 早期版本尤其明显），应拆成两步：先存中间结果，再查
最易被忽略的一点：视图的“简洁性”是假象。它掩盖了执行路径的不可控性——你看到的是一个名字，数据库执行的却是一张嵌套五层的执行计划图。真要保性能，得从展开那一刻就开始干预。
