数据库查询优化中的查询分解（Query Decomposition）与视图合并（View Merging）技术进阶

描述
查询分解与视图合并是数据库优化器处理复杂查询（特别是包含视图或派生表的查询）的核心技术。查询分解指将复杂的查询块拆分为更简单的逻辑单元，而视图合并则尝试将视图或内联视图的逻辑直接合并到主查询中，消除临时物化开销，为优化器创造更多的连接顺序选择、谓词下推等优化机会。在高阶场景中，优化器需智能判断何时合并、何时保留独立计算，这直接影响执行计划的质量。

解题过程

1. 理解视图的默认处理方式

   • 当查询包含视图时，数据库最初会将其视为独立的"黑盒"：先执行视图定义的查询，将结果物化为临时中间表，再基于此中间表执行主查询的剩余操作。
   • 示例：

     CREATE VIEW HighSalaryEmps AS 
     SELECT emp_id, dept_id, salary FROM employees WHERE salary > 100000;
     
     SELECT * FROM HighSalaryEmps WHERE dept_id = 10;
     

     • 未优化时，数据库会先全量计算HighSalaryEmps视图（物化所有高薪员工），再过滤dept_id = 10。

2. 视图合并的基本原理

   • 优化器尝试将视图的定义"内联"到主查询中，重写查询为等价的无视图形式，从而将视图中的条件与主查询条件合并。
   • 合并后等价查询：

     SELECT emp_id, dept_id, salary 
     FROM employees 
     WHERE salary > 100000 AND dept_id = 10;
     

   • 优势：
     • 允许将dept_id = 10条件下推到表扫描阶段，减少读取的数据量。
     • 可为(dept_id, salary)等复合索引提供使用机会。

3. 视图合并的适用条件与限制

   • 可合并的视图类型：
     • 无聚合、无DISTINCT、无窗口函数、无GROUP BY的简单视图（如示例）通常直接合并。
     • 含GROUP BY的聚合视图在满足特定条件时也可合并（如主查询不修改分组粒度）。
   • 阻止合并的因素：
     • 视图包含ROWNUM、TOP等限制结果集的操作。
     • 主查询对视图列进行函数调用（如UPPER(view_column)）。
     • 视图定义包含UNION等集合操作（部分数据库支持有限合并）。

4. 聚合视图的合并场景分析

   • 示例：

     CREATE VIEW DeptSalaryStats AS 
     SELECT dept_id, AVG(salary) AS avg_sal FROM employees GROUP BY dept_id;
     
     SELECT * FROM DeptSalaryStats WHERE dept_id IN (10, 20);
     

     • 若直接物化视图，会先计算所有部门的平均工资，再过滤部门。
     • 合并后：将聚合操作与过滤条件结合，仅对部门10和20计算平均值：

       SELECT dept_id, AVG(salary) AS avg_sal 
       FROM employees 
       WHERE dept_id IN (10, 20) 
       GROUP BY dept_id;
       

   • 复杂情况：若主查询需对聚合结果进一步过滤（如HAVING avg_sal > 50000），合并后仍可正常应用HAVING子句。

5. 查询分解在子查询中的应用

   • 对复杂的相关子查询或派生表，优化器可能将其分解为多个逻辑块，分别优化后再组合。
   • 示例：

     SELECT * FROM orders o 
     WHERE o.amount > (SELECT AVG(amount) FROM orders WHERE cust_id = o.cust_id);
     

     • 优化器可能将其分解为"计算每个客户平均金额"和"主订单过滤"两个部分，尝试转换为连接或窗口函数。

6. 优化器的代价权衡

   • 并非所有视图都适合合并。优化器会基于代价模型选择策略：
     • 保留独立计算的情况：
       • 视图被主查询多次引用时，物化可避免重复计算。
       • 视图结果集远小于基表，且主查询过滤性差时，物化可能更高效。
     • 合并的代价评估：
       • 合并后可能导致连接顺序空间爆炸，需平衡优化时间与计划质量。

7. 人工干预策略

   • 使用NO_MERGE提示强制物化视图，或MERGE提示鼓励合并。
   • 对于复杂查询，可通过比较执行计划判断合并是否生效，并调整查询写法或索引设计。

通过以上步骤，数据库在保持语义正确的前提下，动态选择分解与合并策略，最大化利用基表索引与条件过滤，减少中间结果规模，从而提升查询性能。