THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
但是QueryOperator并没有进行良好的抽象，随着IoTDB查询类型和查询功能不断增多，导致其内部结构逐渐复杂和臃肿，各类查询的特殊声明都聚集在一起，例如下图中第一个红框内代表Group by查询的特殊声明，而第二个红框内代表Fill查询的特殊声明。这种冗杂在一起的存储，不仅造成了内部存储的冗余，同时也必须为每一种查询类型建立一个标志位以在外部判断，从而造成了外部结构的混乱，导致了大量的冗余判断。
图2.3 QueryOperator内部成员变量图
...
一般，原始数据查询只会包含后缀路径，聚合函数会在聚合查询和降采样查询时出现，而UDF函数只会出现在UDF查询中。如果可以将这些分开存储的部分抽象为一个整体，而把这些部分作为子类，并利用多态重写基类方法，就可以将外部的判断和操作移到各部分内部进行，大幅减少外部逻辑判断，优化整体代码结构。
图2.4 SelectOperator内部存储结构图
...
对于QueryOperator内部的特殊声明部分，计划先将其抽象为一个整体，即SpeicalClauseComponent类，然后对于不同的查询特殊声明，再实现各自的子类。由此，QueryOperator包含如下图2.5所示的4个部分，简洁清晰。
图2.5 QueryOperator优化后内部成员变量图
...
我们首先来看由第四部分确定的4种查询，这四种查询的主要区别在于特殊声明部分不同。我们计划先将所有查询共有的特殊声明部分抽象为SpecialClauseComponent，其中包括行数限制，行偏移量限制，是否需要包含空值列等信息。然后，再分别为这四种查询建立特殊声明子类，存储这些查询特有的信息。需要特别说明的是，AlignByDevice即按设备对齐查询是IoTDB为了满足用户对于关系表的需要设计的另一种结果集展示方式，其以时间和设备为主键，先按设备对齐，设备内再按时间对齐。该查询本质上可能是任意查询，差别仅在于结果集展示方式的不同。因此，我们计划将其作为特殊声明基类中的一个公共字段，可以与任何查询作笛卡尔积，而不是作为一个单独的特殊声明子类。
图2.6 特殊声明部分类继承结构图
接着来看由第一部分确定的四种查询，这四种查询的主要区别自在于Select部分的对外表现不同，例如原始数据查询只包含时间序列路径，而聚合查询中还包含聚合函数。我们计划将原本分开的部分抽象为一个整体ResultColumn类，其可以根据Select部分有不同的子类表现形式，具体如下图所示：，具体如下图所示（具体见宇荣部分）：
图2.7 ResultColumn及Expression部分成员结构图
由此，我们对IoTDB每个查询的内部变量进行了重新设计，接下来我们需要为每个查询新建外部的逻辑运算符，其继承结构如下图所示：
图2.8 QueryOperator 继承结构图
最后，我们得到的整体的类图，如下图所示：
图2.9 逻辑查询计划设计总类图
...