元组查询执行

导言

      毫不夸张的说内存DBMS的性能主要由内存操作决定。因为把数据库的全部放到内存上管理，所以需要在数据操作时使用最小化存储器的访问和操作次数的算法。DBMS的性能在很大程度上取决于应用的实现，因为查询处理模块的大部分运算是在CPU和存储器之间进行的。所以，内存DBMS的开发不仅要开发数据存储模块，还得要下功夫开发查询处理模块。

      一般的，查询处理器解析SQL语句，生成执行计划。执行计划是树状结构，每个树节点执行projection, Join, Selection的单元操作。操作从操作树最下面的节点开始执行相应的操作，把结果作为输入值传达到其父节点。最后，根节点的操作结果就是相应SQL语句的查询结果。

      现在的查询处理方法大部分使用流水线操作法，但Altibase使用Tuple-set查询处理方式，此方式最大限度地利用了常驻存储器的特点。 下面简要地看一下这些技术。

流水线查询处理

      这种方法采取把子节点的操作结果制作成临时表传达给父节点的方法。假如处理'SELECT T1.I1, T2.I2 FROM T1, T2;'这个SQL语句时如下图所示，最下边的两个扫描节点各自扫描处理T1、T2后做成临时表传达到它们的父节点（JOIN）。JOIN节点根据条件执行两个表格的连接操作，把此结果做成临时表又传达到上层节点(PROJ)。最终，PROJ节点通过映射收到的临时表相应的列得到结果。

流水线查询处理方法容易体现，但有以下问题。

-生成和注册临时表的多余成本。
-最坏的情况下临时表可能占用整个内存空间。
-频繁的内存复制会导致性能的降低。

Tuple-set查询处理

      这种又被叫做基于行指针查询处理（Row Pointer-based）的查询处理方法与流水线查询方法相同也是从计划树的最下面的节点开始访问，但是和流水线查询方法相比有以下几点区别：

-子节点执行自己的任务，不考虑父节点干什么。
-各个节点的操作结果不做成临时的表格。
-只存储操作结果和Tuple-set数据结构中相应的行指针。

这种查询处理方法有以下特征：

-需要高难度的实现技术。
-不建临时表，所以节约内存空间。
-执行节点的操作结果只是相应行的指针，所以内存复制明显减少。
-快速处理查询。