在数据库开发中，视图常被用来封装查询逻辑，但当我们把视图嵌套在另一个视图中，甚至多层嵌套时，往往会发现系统的物理读取次数异常增多，I/O压力陡然上升。要理解这个问题，需要先看清视图在SQL引擎中的处理方式以及嵌套带来的执行放大效应。
视图的本质与执行方式
视图本身不存储任何数据，它只是一个保存起来的SELECT语句。当查询引用视图时，数据库优化器会把视图定义展开到外层查询中，生成最终的执行计划。如果视图A内部引用了视图B，那么B的定义会被嵌入A，再被嵌入你的查询，形成一层层展开。
简单视图嵌套示例
假设我们有如下三层视图结构：
-- 基础表 CREATE TABLE orders ( id INT, user_id INT, amount DECIMAL(10,2), created_at DATE ); -- 视图1：过滤有效订单 CREATE VIEW v_valid_orders AS SELECT id, user_id, amount FROM orders WHERE amount > 0; -- 视图2：嵌套视图1，按用户聚合 CREATE VIEW v_user_summary AS SELECT user_id, SUM(amount) AS total FROM v_valid_orders GROUP BY user_id; -- 视图3：嵌套视图2，筛选大客户 CREATE VIEW v_vip AS SELECT user_id, total FROM v_user_summary WHERE total > 1000;
当你执行SELECT * FROM v_vip，优化器实际要把三层定义全部展开，等价于直接扫描orders表并做过滤和分组。如果外层还有join或where，展开后的语句会更复杂。
为什么嵌套会导致物理读取次数变多
嵌套视图引发I/O压力过大的核心原因有三点：
- 重复展开导致基础表被多次扫描，尤其当视图被不同分支引用时；
- 优化器难以跨越视图边界做整体裁剪，索引利用不充分；
- 统计信息在视图层可能失真，生成次优计划，引发全表扫描。
用物理读取指标观察问题
在MySQL中可通过以下语句查看实际I/O：
SET profiling = 1; SELECT * FROM v_vip; SHOW PROFILE ALL; -- 关注 Status 中 'Sending data' 及 'Disk' 相关，或查询 SELECT * FROM information_schema.PROFILING WHERE QUERY_ID = 1 AND STATE = 'Sending data';
在SQL Server中可用：
SET STATISTICS IO ON; SELECT * FROM v_vip; -- 消息区会显示 Table 'orders'. Scan count 及 physical reads
| 场景 | 物理读次数 | 说明 |
|---|---|---|
| 直接查基础表并聚合 | 较低 | 优化器一次扫描完成 |
| 三层嵌套视图查询 | 明显偏高 | 展开后可能重复访问 |
减少嵌套视图I/O的改写建议
1. 拍平视图逻辑
把多层视图合并为一个查询，让优化器看到全貌：
SELECT user_id, SUM(amount) AS total FROM orders WHERE amount > 0 GROUP BY user_id HAVING SUM(amount) > 1000;
2. 使用内联表值函数或CTE
在支持CTE的库中，用WITH子句替代视图嵌套，通常更易被优化：
WITH valid_orders AS ( SELECT id, user_id, amount FROM orders WHERE amount > 0 ) SELECT user_id, SUM(amount) AS total FROM valid_orders GROUP BY user_id HAVING SUM(amount) > 1000;
3. 为基表建立合适索引
针对过滤和分组字段建索引，降低每次展开的扫描成本：
CREATE INDEX idx_orders_amount_user ON orders(amount, user_id);
通过以上方式，可以显著减少物理读取次数，缓解因视图嵌套带来的磁盘I/O压力。