数据库查询优化中的聚合下推（Aggregation Pushdown）技术

1. 问题描述
在数据库查询中，聚合操作（如SUM、COUNT、AVG等）通常需要处理大量数据。如果聚合操作能在查询的早期阶段执行，而不是在全部数据加载后执行，可以显著减少中间结果的数据量，从而提升查询性能。聚合下推是一种优化技术，其核心思想是将聚合操作尽可能下推到查询计划中更靠近数据源的节点（如表扫描或连接操作之前）执行。

2. 为什么需要聚合下推？
假设一个查询涉及多表连接和分组聚合：

SELECT t1.category, COUNT(t2.order_id)  
FROM products t1  
JOIN orders t2 ON t1.product_id = t2.product_id  
WHERE t1.price > 100  
GROUP BY t1.category;  

未经优化的执行计划可能先完成连接和过滤，再对大量中间结果进行聚合。但如果先对单表进行局部聚合（如先按category分组统计订单数），再执行连接，中间数据量会大幅减少。

3. 聚合下推的适用场景

• 分组键与连接键兼容：如果分组键是连接操作中的驱动表（如products.category），且连接后分组键不会被破坏（如一对多连接中，category在连接后仍保持唯一性），则可下推聚合。
• 聚合函数可分解：如COUNT、SUM、AVG可拆分为局部聚合（部分结果）和全局聚合（合并结果）。例如，AVG可下推为局部SUM和COUNT，最终再计算SUM/COUNT。
• 过滤条件下推配合：若WHERE条件仅涉及单个表，可先过滤再聚合，进一步减少数据量。

4. 聚合下推的实现步骤
步骤1：查询重写
将原始查询分解为局部聚合和全局聚合：

• 局部聚合：在数据源节点（如orders表）先按product_id分组，计算每个产品的订单数（COUNT(order_id)）。
• 全局聚合：连接后按category分组，合并局部聚合结果（如对同一category的订单数求和）。

重写后的查询可能对应以下执行计划：

-- 局部聚合（下推到orders表扫描后）  
SELECT product_id, COUNT(order_id) AS partial_count  
FROM orders  
GROUP BY product_id;  

-- 最终查询  
SELECT t1.category, SUM(partial_count)  
FROM products t1  
JOIN (上述局部聚合结果) t2 ON t1.product_id = t2.product_id  
WHERE t1.price > 100  
GROUP BY t1.category;  

步骤2：执行计划优化
优化器通过以下逻辑决定是否下推聚合：

1. 代价估算：比较下推前后中间结果的数据量。例如，若orders表有1亿行，而products表仅1万行，先按product_id聚合可将订单数据压缩为1万行局部结果，大幅减少连接成本。
2. 保持语义正确性：确保下推后结果与原始查询一致。例如，若连接操作可能改变分组键的唯一性（如多对多连接），则不能直接下推。

步骤3：分布式数据库中的扩展
在分布式数据库（如ClickHouse、Spark）中，聚合下推可结合数据分布特性：

• 先在每个数据分片上进行局部聚合；
• 再将局部结果汇总到协调节点进行全局聚合。
  此法减少网络传输数据量，适合大规模数据处理。

5. 注意事项与限制

• 聚合函数限制：MIN/MAX可直接下推，但DISTINCT COUNT需谨慎处理（需避免重复计数）。
• 嵌套聚合不支持：如AVG(SUM(x))无法简单下推。
• 连接类型影响：外连接可能产生NULL值，需确保聚合函数对NULL的处理符合语义（如COUNT忽略NULL）。

6. 实际案例
在TPC-H查询中，Q1（线性统计查询）的聚合操作可直接下推到分区扫描阶段，减少90%的中间数据传输。在Oracle或PostgreSQL中，可通过EXPLAIN命令观察优化器是否生成HashAggregate节点靠近表扫描，判断聚合下推是否生效。

通过将聚合操作下推到查询底层，数据库显著降低了计算和I/O开销，尤其适用于大数据量和高并发场景。