数据库查询优化中的视图合并（View Merging）优化原理解析

一、视图合并的概述

视图合并是数据库查询优化器将SQL中引用的视图定义“拆解”并合并到主查询中的技术。它消除了视图的封装边界，使优化器能对整体查询进行更全面的优化。

为什么需要视图合并？
如果视图不合并，优化器会将视图当作一个独立的“黑盒”来生成执行计划，可能导致：

1. 子查询被物化（临时表），产生额外I/O与内存开销
2. 无法跨视图边界进行谓词下推、连接重排序等优化
3. 优化范围受限，生成次优计划

视图合并的目标：打破视图的隔离性，让优化器将视图逻辑与主查询作为一个整体进行优化。

二、视图合并的适用场景

视图合并通常在以下情况被触发：

1. 视图定义简单：不包含聚合（GROUP BY）、窗口函数（OVER）、DISTINCT、集合操作（UNION）等复杂结构
2. 视图可内联：优化器判断合并后的查询语义等价于原查询
3. 无禁止合并的语法：例如某些数据库支持 NO_MERGE 提示阻止合并

示例：

-- 原视图定义
CREATE VIEW v_employees AS
SELECT id, name, dept_id FROM employees WHERE status = 'active';

-- 查询使用视图
SELECT v.name, d.dept_name 
FROM v_employees v 
JOIN departments d ON v.dept_id = d.id 
WHERE v.id > 1000;

-- 合并后等价查询
SELECT e.name, d.dept_name 
FROM employees e 
JOIN departments d ON e.dept_id = d.id 
WHERE e.status = 'active' AND e.id > 1000;

合并后，条件 e.id > 1000 和 e.status = 'active' 可被同时下推至 employees 表，并能自由调整连接顺序。

三、视图合并的具体步骤

第1步：视图解析与展开
优化器从系统目录中获取视图的定义SQL，将其解析为查询块（Query Block）。
例如：
视图 v_employees 对应的查询块为：

SELECT id, name, dept_id 
FROM employees 
WHERE status = 'active'

第2步：合法性检查
检查合并是否保持语义等价，关键约束包括：

• 无重复列名冲突：如果视图与主查询有同名列且含义不同，需重命名
• 无聚合/窗口函数：若视图包含聚合，合并可能改变分组范围（通常不合并）
• 无行数限制：视图含 LIMIT/TOP 时，合并可能改变预期行数（需谨慎）
• 无外部引用：视图定义若引用主查询的列（相关子查询），则不能简单合并

第3步：查询块融合
将视图查询块与主查询块合并为单一查询块，步骤包括：

1. 表引用合并：将视图中的表（如 employees）引入主查询的FROM列表
2. 谓词合并：将视图的WHERE条件（status='active'）与主查询条件合并
3. 列引用替换：将主查询中对视图列的引用（v.name）替换为基表列（employees.name）
4. 连接条件保留：主查询与视图间的连接条件（如 ON v.dept_id = d.id）转为基表间的连接

第4步：优化整合
合并后，优化器可对整体查询应用优化技术：

• 谓词下推：所有条件可下推至基表
• 连接重排序：基表 employees 与 departments 可自由调整连接顺序
• 索引选择：基于合并后的条件选择最佳索引

四、视图合并的复杂场景处理

场景1：多视图嵌套合并

CREATE VIEW v1 AS SELECT * FROM t1 WHERE c1 > 10;
CREATE VIEW v2 AS SELECT * FROM v1 WHERE c2 = 'A';
SELECT * FROM v2 WHERE c3 < 100;

优化器递归合并：

1. 将 v2 替换为 v1 的定义 + 条件 c2='A'
2. 再将 v1 替换为 t1 的定义 + 条件 c1>10
3. 最终合并为：SELECT * FROM t1 WHERE c1>10 AND c2='A' AND c3<100

场景2：视图含连接时的合并

CREATE VIEW v_dept_emp AS
SELECT e.id, e.name, d.dept_name 
FROM employees e JOIN departments d ON e.dept_id = d.id;

SELECT * FROM v_dept_emp WHERE id > 1000;

合并后：

• 将 employees 和 departments 加入主查询FROM
• 保留连接条件 e.dept_id = d.id
• 将条件 id > 1000 转化为 e.id > 1000

场景3：无法合并的情况

若视图定义包含以下结构，通常不合并：

• 聚合查询：GROUP BY、SUM() 等
• 集合操作：UNION、INTERSECT
• 窗口函数：ROW_NUMBER() 等
• DISTINCT：可能改变行唯一性语义
  此时，优化器可能将视图物化为临时表再处理。

五、视图合并的收益与代价

收益：

1. 提升性能：消除物化开销，扩大优化空间
2. 利用索引：合并后条件可直接使用基表索引
3. 简化计划：减少查询块数量，降低执行复杂度

代价与风险：

1. 优化时间增加：合并过程增加编译开销
2. 可能误合并：复杂视图合并后语义可能改变（如含 LIMIT）
3. 计划不稳定：合并可能导致计划突变，影响性能一致性

六、数据库中的控制机制

多数数据库提供方式控制合并行为：

• Oracle：MERGE / NO_MERGE 提示

  SELECT /*+ NO_MERGE(v) */ * FROM v_employees v WHERE ...`
  

• SQL Server：自动合并，可通过索引视图等方式间接控制
• PostgreSQL：简单视图自动合并，复杂视图使用子查询物化

七、总结

视图合并是优化器打破模块化边界、实现全局优化的关键技术。它通过将视图定义内联到主查询，使谓词下推、连接重排序等优化能跨越视图边界。尽管对简单视图效果显著，但需注意复杂视图合并的语义风险。理解这一机制有助于编写更易优化的视图与查询。