Apache Ignite 查询优化中的 UNION_MERGE 规则内存问题分析

在分布式数据库系统 Apache Ignite 的查询优化过程中，我们发现了一个可能导致内存爆炸的性能问题。这个问题与查询计划优化器中的 UNION_MERGE 规则直接相关，当处理包含大量 UNION ALL 和子查询的复杂 SQL 时，会产生严重的性能瓶颈。

问题背景

在 Ignite 的查询优化阶段，PlannerPhase#OPTIMIZATION 会应用一系列优化规则来改进查询执行计划。其中 CoreRules.UNION_MERGE 规则的设计初衷是合并相邻的 UNION ALL 操作，减少中间结果集的生成，从而提高查询效率。然而，在实际应用场景中，这个优化规则在某些特定情况下会产生反效果。

问题现象

当 SQL 查询包含多个 UNION ALL 操作和复杂子查询时，应用 UNION_MERGE 规则后会生成一个包含大量子节点的 IgniteUnionAll 操作符。例如，在一个包含9个子节点的 UNION ALL 操作中，如果每个子节点有7种可能的执行计划变体，那么总的计划组合数将达到7的9次方（约4000万种可能性）。

这种组合爆炸会导致以下问题：

1. 查询优化器的计划空间急剧膨胀
2. TraitUtils#fillRecursive 方法中的结果 HashSet 占用大量内存
3. Java 程序因频繁垃圾回收(GC)而陷入停滞状态

技术原理分析

Ignite 的查询优化器基于 Apache Calcite 框架构建，采用基于成本的优化(CBO)策略。在优化过程中，系统会枚举各种可能的执行计划变体，计算它们的成本，并选择最优方案。

UNION_MERGE 规则的工作原理是将多个连续的 UNION ALL 操作合并为一个操作，减少中间结果的物化。例如：

SELECT * FROM (SELECT * FROM A UNION ALL SELECT * FROM B) UNION ALL SELECT * FROM C

会被优化为：

SELECT * FROM A UNION ALL SELECT * FROM B UNION ALL SELECT * FROM C

这种优化在简单场景下确实能提高性能，但当 UNION ALL 操作数量较多且每个分支包含复杂子查询时，合并后的 UNION ALL 操作会包含大量子节点，导致计划空间组合爆炸。

解决方案

针对这个问题，我们建议采取以下措施：

1. 禁用相关优化规则：在查询优化阶段完全禁用可能导致问题的规则，包括：

   • CoreRules.UNION_MERGE
   • CoreRules.MINUS_MERGE
   • CoreRules.INTERSECT_MERGE

2. 引入启发式限制：可以考虑在规则应用中添加限制条件，例如：

   • 当 UNION ALL 操作超过一定数量时禁用合并
   • 当子查询复杂度超过阈值时禁用合并

3. 内存使用监控：在优化过程中加入内存使用监控机制，当检测到内存压力时自动回退到保守策略

实施建议

对于使用 Ignite 的开发人员，如果遇到类似性能问题，可以：

1. 检查查询计划中是否存在合并了大量子节点的 UNION ALL 操作
2. 通过配置临时禁用相关优化规则进行验证
3. 考虑重写查询，将大型 UNION ALL 操作拆分为多个阶段

总结

查询优化是一把双刃剑，在提高大多数场景性能的同时，也可能在特定情况下导致严重问题。Apache Ignite 中的 UNION_MERGE 规则问题提醒我们，在分布式数据库系统的优化器设计中，需要更加谨慎地处理可能导致组合爆炸的优化策略，并在规则应用中加入适当的限制条件和保护机制。