CrateDB中UNNEST子查询的过滤器下推优化问题分析

概述

在CrateDB数据库使用过程中，我们发现了一个关于查询优化器在处理UNNEST子查询时过滤器下推行为的性能优化问题。当查询涉及嵌套对象字段时，优化器无法像处理普通列那样有效地将过滤条件下推到子查询中执行，这可能导致不必要的全表扫描和性能下降。

问题现象

我们通过两个测试案例来展示这个问题：

1. 基础表结构测试：

CREATE TABLE test_unnest1 (
    field1 INT,
    arr ARRAY(OBJECT)
);

在这个表中，当我们在外层查询中对field1列应用过滤条件时，优化器能够成功将过滤条件下推到子查询中执行。

2. 嵌套对象结构测试：

CREATE TABLE test_unnest2 (
    document OBJECT AS (
        field1 INT,
        arr ARRAY(OBJECT)
);

当同样的过滤条件应用于嵌套对象(document['field1'])时，优化器无法将过滤条件下推，导致执行计划中出现全表扫描(MatchAllDocsQuery)而非预期的范围查询(PointRangeQuery)。

技术原理分析

查询优化器在处理这类查询时，通常会尝试将过滤条件下推到尽可能靠近数据源的位置执行，这一过程称为"过滤器下推"。理想情况下，过滤条件应该在数据读取阶段就应用，减少后续处理的数据量。

在CrateDB中，这一优化过程通过多个优化规则完成：

1. optimizer_move_filter_beneath_rename：将过滤器下推到重命名操作下方
2. optimizer_move_filter_beneath_eval：将过滤器下推到表达式计算下方
3. optimizer_move_filter_beneath_project_set：将过滤器下推到项目集操作下方

对于普通列的情况，这些优化规则能够正常工作，最终将过滤条件合并到Collect操作中。但对于嵌套对象字段，优化器在optimizer_move_filter_beneath_project_set阶段未能成功下推过滤器。

性能影响

这种优化失败会导致：

1. 需要读取并处理更多不必要的数据
2. 增加了UNNEST操作的计算量
3. 无法利用索引加速查询
4. 内存使用量增加

特别是在处理大型数据集或复杂视图时，这种性能差异会非常明显。

解决方案建议

目前可以通过以下方式规避此问题：

1. 手动下推过滤条件：将过滤条件显式地写在子查询内部
2. 重构数据模型：考虑将常用过滤字段提升到顶层列
3. 使用函数索引：为嵌套字段创建函数索引

从长期来看，这需要CrateDB开发团队对查询优化器进行增强，使其能够正确处理嵌套对象字段的过滤器下推逻辑。

总结

CrateDB在处理包含UNNEST的子查询时，对于嵌套对象字段的过滤器下推存在优化不足的问题。开发者和DBA在设计数据模型和编写查询时应当注意这一限制，采取适当的规避措施以确保查询性能。我们也期待未来版本中能够看到这一优化能力的改进。