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

描述
查询分解与视图合并是数据库优化器处理复杂查询（特别是包含视图或派生表的查询）的重要技术。当查询涉及视图、派生表或公共表表达式（CTE）时，优化器需要决定如何将这些逻辑单元整合到整体执行计划中。视图合并旨在将视图的定义直接嵌入主查询，消除临时物化开销，从而暴露更多优化机会（如谓词下推、连接重排序）；而查询分解则可能将复杂查询拆分为多个可独立优化的部分。这两种技术共同解决"黑箱化"视图导致的性能瓶颈。

解题过程

1. 问题识别

   • 当查询包含视图或派生表时，例如：

     SELECT * FROM orders o
     JOIN (SELECT customer_id, SUM(amount) as total 
           FROM payments GROUP BY customer_id) p 
     ON o.customer_id = p.customer_id
     WHERE o.amount > 1000;
     

   • 若直接执行子查询p并物化临时结果，可能阻碍谓词o.amount > 1000与内层查询的关联，导致全表扫描或低效连接。

2. 视图合并（View Merging）的核心步骤

   • 步骤1：语法树解析
     优化器将查询解析为抽象语法树（AST），视图或派生表被标记为独立子树。
     • 示例中派生表p对应子树：GROUP BY payments ON customer_id。
   • 步骤2：合法性检查
     确保合并不会改变查询语义，以下情况通常禁止合并：
     • 视图包含DISTINCT、GROUP BY、聚合函数且外层查询有额外过滤条件（可能影响聚合范围）。
     • 视图使用ROWNUM、窗口函数等顺序敏感操作。
     • 本例中派生表含GROUP BY，但外层仅做等值连接，合并可能可行。
   • 步骤3：查询重写
     将视图定义内联（Inline）到主查询，生成合并后的逻辑计划：

     -- 合并后等效查询
     SELECT o.*, p.total 
     FROM orders o 
     JOIN payments p ON o.customer_id = p.customer_id 
     WHERE o.amount > 1000 
     GROUP BY o.customer_id, o.*, p.total;  -- 需补充GROUP BY以保持语义
     

     实际优化器会自动调整GROUP BY列表以确保合法性。
   • 步骤4：优化机会暴露
     合并后，优化器可：
     • 将谓词o.amount > 1000下推到payments表连接前执行（减少连接数据量）。
     • 重新评估连接顺序（如先过滤orders再连接）。

3. 查询分解（Query Decomposition）的适用场景

   • 当视图合并不可行时（如含DISTINCT的复杂视图），优化器可能将查询分解为多个子计划：
     • 步骤1：子查询物化
       将视图结果物化为临时表，例如：

       -- 物化派生表p
       CREATE TEMP TABLE p AS 
       SELECT customer_id, SUM(amount) as total FROM payments GROUP BY customer_id;
       

     • 步骤2：分层优化
       先优化子查询（如为payments表添加索引加速聚合），再优化主查询的连接策略。
     • 局限性：物化可能增加I/O开销，尤其当临时表过大时。

4. 优化器决策逻辑

   • 基于代价模型比较合并与分解的代价：
     • 合并代价：评估重写后查询的连接顺序、索引使用可能性。
     • 分解代价：计算物化临时表的存储成本+二次查询执行成本。
   • 示例中，若orders表数据量远大于payments，合并后利用o.amount索引过滤可能更优；若payments表巨大且无合适索引，物化反而避免重复扫描。

5. 实际应用技巧

   • 使用EXPLAIN分析执行计划：
     • 若计划中出现"Subquery Scan"或"Materialize"，说明未合并；若直接显示合并后的表连接，则合并生效。
   • 人工提示优化器：
     • 如MySQL的MERGE/NO_MERGE提示强制控制视图合并行为。

通过视图合并消除中间层，优化器能更自由地应用谓词下推、连接重排序等技术，而查询分解则在合并不可行时提供备选路径。理解这一机制有助于编写易于优化的SQL语句（如避免在视图中使用不必要的DISTINCT）。