在数据库日常使用中，很多开发者会将复杂的查询逻辑封装成视图方便复用，但经常会遇到包含子查询的视图执行速度远低于预期的情况。这种性能问题的根源在于视图的展开机制以及子查询嵌套带来的额外开销。
视图展开的基本机制
视图本身并不存储实际的数据，它本质上是一条预定义的查询语句。当我们在查询中引用视图时，数据库优化器首先会执行视图展开操作：将视图的定义语句直接替换到主查询的对应位置，形成一个完整的、未优化的查询树，之后再基于这个合并后的查询树生成执行计划。
比如我们有一个简单的视图定义如下：
-- 定义一个查询用户最近订单的视图 CREATE VIEW user_recent_order AS SELECT user_id, order_id, order_time FROM orders WHERE order_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY);
当执行SELECT * FROM user_recent_order WHERE user_id = 100时，数据库会先将视图展开，等效为如下查询再生成执行计划：
SELECT user_id, order_id, order_time FROM orders WHERE order_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND user_id = 100;
子查询在视图中带来的额外嵌套开销
如果视图内部包含子查询，展开后的结构会变得更加复杂，主要会带来以下几类开销：
1. 优化器成本评估偏差
数据库优化器在生成执行计划时，需要评估不同执行路径的成本。当视图中包含子查询时，展开后的查询树层级会增多，优化器可能无法准确统计子查询返回的行数、数据分布等信息，导致选择非最优的执行路径。
例如下面这个包含子查询的视图：
-- 定义视图，查询订单金额高于用户平均订单金额的订单
CREATE VIEW high_value_order AS
SELECT o.order_id, o.user_id, o.amount
FROM orders o
WHERE o.amount > (
SELECT AVG(amount)
FROM orders
WHERE user_id = o.user_id
);
当主查询引用这个视图并加上过滤条件WHERE user_id = 100时，展开后的查询会包含两层嵌套的关联子查询。优化器可能无法意识到外层的user_id = 100条件可以同时应用到子查询中，导致子查询对全表进行扫描计算平均值，带来不必要的IO开销。
2. 无法有效使用索引
子查询的存在可能会阻断优化器对索引的使用。比如视图中的子查询如果使用了聚合函数、DISTINCT等操作时，展开后可能无法和外层的过滤条件形成有效的索引匹配组合，导致原本可以走索引的查询变成全表扫描。
我们可以通过执行计划对比直接查询和视图查询的差异：
| 查询方式 | 执行计划核心操作 | 扫描行数 |
|---|---|---|
| 直接编写完整查询 | 先通过user_id索引过滤主查询，子查询同步使用user_id索引计算平均值 | 100 |
| 通过包含子查询的视图查询 | 主查询全表扫描，子查询全表扫描计算平均值 | 10000 |
3. 临时表创建开销
部分数据库在处理视图中的子查询时，如果无法将其合并到主查询中，会先将子查询的结果存入临时表，再和主查询的数据进行关联。临时表的创建、数据存储和后续读取都会带来额外的内存和IO开销，尤其是子查询结果集较大时，性能下降会非常明显。
优化建议
针对视图中子查询性能较差的问题，可以尝试以下优化方案：
- 尽量避免在视图中使用复杂的子查询，尤其是关联子查询，可以将子查询逻辑拆分到主查询中，或者改用JOIN的方式实现相同逻辑。
- 如果必须使用视图，可以考虑将视图改为物化视图（如果数据库支持），提前计算并存储视图的结果，避免每次查询都重新展开执行。
- 给视图中涉及的查询字段建立合适的联合索引，帮助优化器在展开后的查询中更准确地选择执行路径。
- 定期分析视图的执行计划，对比直接查询的执行计划，定位展开后出现的性能瓶颈点。
总的来说，视图中子查询的性能问题核心是展开后带来的嵌套复杂度超过了优化器的处理能力，在实际开发中需要结合具体的业务场景和数据库特性，选择合适的优化方式。