0.13.0-SNAPSHOT 版本现状

尽管IoTDB包含大量的查询类型，但是查询的 operator 只有基类的 QueryOperator，所有查询相关的标志位和参数都存储在同一个类中，包括聚合查询、GroupBy查询、AlignByDevice 等等。

这显然造成了存储的冗余，且结构混乱。因此需要将逻辑查询运算符的子类抽取出来，并对相应的过程逻辑进行相应的修改。一方面，这样类结构更加清晰，方便维护；另一方面，对于不同的查询类型创建不同的查询运算符，有利于之后将复杂的查询计划转换逻辑下放到各个查询运算符内，从而减少外部逻辑，方便计算。

设计方案

查询语句的 SQL 解析按顺序主要分为 4 个部分：

我们重点关注第一部分和第四部分。

在查询语句中，一部分查询的类型是由第一部分确定的，另一部分查询的类型是由第四部分确定的。

如聚合查询, select count(s1) from root.sg.d1，显然由 SELECT 子句，即第一部分确定。

而 Group by 查询，select count(s1) from root.sg.d1 group by ([1, 10), 2ms)，则由第四部分确定。

总结：

由第一部分确定的查询类型包括：

由第四部分确定的查询类型包括：

我们计划为每种查询类型新建一个逻辑运算符，如为 Group by 新建 GroupByQueryOperator，以此方便之后物理计划生成的重构，即将物理计划生成放在不同种类的逻辑运算符内完成。

此前，是按照 SELECT -> FROM -> WHERE -> SpecialClause 的顺序进行解析，这显然不再合理，因为没办法提前知道由第四部分决定的查询类型。

因此，计划将解析顺序改为，SpecialClause -> SELECT -> FROM -> WHERE，这种解析顺序可以提前知道每一种查询的类型并新建该逻辑运算符。

接下来看由第一部分确定的 4 个查询：

首先明确一个概念，QueryOperator 继承自 SFWOperator。

其中有三个成员变量，SelectOperator，FromOperator 和 FilterOperator。

SFWOperator 的继承类包括：

以 DeleteOperator 为例：

其只是为了利用 SelectOperator 中的前（后）缀路径。

这显然是当时设计的时候图省事，就直接让这几个类继承 SFW 了。SFWOperator 还有对于 Where 子句中过滤条件的优化，这是 Insert、Delete 等运算符根本没必要去跑的。

因此，这些类可以从 SFWOperator 的子类中分离出来。（这部分交给宇荣去做了）

此时，SFWOperator 就可以直接干掉，其中的成员变量直接拿到 QueryOperator 内。因为其只有一个子类为 QueryOperator.

我们继续来看查询部分。

此前，普通查询中 SELECT 子句中的后缀路径，聚合查询中的聚合函数等信息是存储在SFWOperator内的 SelectOperator 内的，而不是存储在 QueryOperator 内里。

这部分中的后缀路径、聚合函数、UDF及算数表达式等信息，都会被包装为一个 List<ResultColumn> 的一个 List，其中相关操作都会在ResultColumn 内部完成，我们暂时不关心内部实现。

于是，由第一部分决定的查询类型对外暴露的 SelectComponent 是相同的，只有 SelectComponent 内部的 ResultColumn 类型不同。

这个在读取到第一个 Select 元素时就可以进行判断，并生成对应的查询类型。

于是最后 QueryOperator 的类图为：

QueryOperator主要内容如下：

这里由于 Select、From 等只用来存储内容，并没有逻辑运算符的特性，因此其不应该继承 Operator，于是重新命名为 XxxComponent。

SpecialClauseCompent 的类图为：